Subject: [TLS] [response[ AD review of draft-ietf-tls-subcerts-11

From: Nick Sullivan <[email-masked]>
Date: Tue, 1 Mar 2022 10:22:03 -0500

TLSWG,

Benjamin Kaduk sent a review to the list of draft 11 of Delegated
Credentials. Somehow I didn't get the email, so I'm restating his points
here with responses. Ben, thanks for the thorough review. If there's
consensus around my proposed responses to the changes, I'll put together an
additional PR to go along with Benjamin's PR and submit a new draft version.

Nick

Hi all,

Generally I like the shape this is in, but there's enough potentially in
flux after this review that I'd like to clean things up with a revised I-D
before I kick off the IETF LC.  I think my comments on §4.2 are the ones
that are most likely to result in any significant discussion.

I made some (hopefully) editorial suggestions in a github PR, though
a couple seemed borderline enough that I mention them here as well.
(https://github.com/tlswg/tls-subcerts/pull/93)

Abstract

(editorial) There seems to be a large jump from the sentence that say
the CA ultimately determines a lot about the certificate and the
sentence describing the mechanism this document describes.  We might
want to help the transition by also saying that the new mechanism
partially overcomes/mitigates those limitations.

[NS]
Proposed changes
Before:
   The organizational separation between the operator of a TLS endpoint
   and the certification authority can create limitations.  For example,
   the lifetime of certificates, how they may be used, and the
   algorithms they support are ultimately determined by the
   certification authority.  This document describes a mechanism by
   which operators may delegate their own credentials for use in TLS,
   without breaking compatibility with peers that do not support this
   specification.

NEW:
   The organizational separation between the operator of a TLS endpoint
   and the certification authority can create limitations.  For example,
   the lifetime of certificates, how they may be used, and the
   algorithms they support are ultimately determined by the
   certification authority.  This document describes a mechanism to
   to overcome some of these limitations by enabling operators to
   delegate their own credentials for use in TLS without breaking
   compatibility with peers that do not support this specification.
[/NS]

Section 1

  However, short-lived certificates need to be renewed more frequently
  than long-lived certificates.  If an external CA is unable to issue a
  certificate in time to replace a deployed certificate, the server
  would no longer be able to present a valid certificate to clients.

(editorial) Most of the document carefully phrases things so that it
does not presume that the DC holder is the TLS server (e.g., in this
section we mostly talk about "server operator"s).  This chunk does
not, and arguably the following paragraph as well.  I didn't come up
with a different phrasing I liked so as to offer it in my PR, though.

[NS]
In this section we are talking about traditional TLS deployments (without
DCs or remote key operations) to motivate the document.  In
these scenarios the certificate is typically deployed to server
may introduce confusion to differentiate between server and certificate
holder.  I don’t think there’s a useful change we can make that improves
clarity.
[/NS]

Section 3

  It was noted in [XPROT] that certificates in use by servers that
  support outdated protocols such as SSLv2 can be used to forge
  signatures for certificates that contain the keyEncipherment KeyUsage
  ([RFC5280] section 4.2.1.3).  In order to prevent this type of cross-
  protocol attack, we define a new DelegationUsage extension to X.509
  that permits use of delegated credentials.  (See Section 4.2.)

If I understand correctly, the extension serves to prevent *existing*
misconfigured servers from being leveraged in a cross-protocol attack to
"sign" DCs usable for TLS 1.3.  As we discuss in §7.6, however, it does
not prevent the attack when such a misconfigured server is given a new
certificate that contains the extension (as might happen if a cert is
shared across the TLS 1.2 and TLS 1.3 backends for a single service and
the TLS 1.2 implementation is unloved).  So maybe we should hedge our
language a bit from "prevent this type of cross-protocol attack".

[NS]
Very good point.

Proposed changes

NEW:
  It was noted in [XPROT] that certificates in use by servers that
  support outdated protocols such as SSLv2 can be used to forge
  signatures for certificates that contain the keyEncipherment KeyUsage
  ([RFC5280] section 4.2.1.3).  In order to reduce the risk of cross-
  protocol attacks on certificates that are not intended to be used
  with DC-capable TLS stacks, we define a new DelegationUsage
  extension to X.509 that permits use of delegated credentials.  (See
Section 4.2.)
[/NS]

Section 3.1

  *  X.509 semantics are very rich.  This can cause unintended
     consequences if a service owner creates a proxy certificate where
     the properties differ from the leaf certificate.  For this reason,
     delegated credentials have very restricted semantics that should
     not conflict with X.509 semantics.

In light of Peter's affirmation that proxy certs remain heavily used in grid
computing
(https://mailarchive.ietf.org/arch/msg/tls/AZQRnOtA-6Am7CM65HX4YSb_vdQ/), I
wonder if we want to make some statement to clarify that proxy certs are
still a useful tool in expert hands, even if the risk we describe is real.

[NS]
Proposed changes

NEW:
  *  X.509 semantics are very rich.  This can cause unintended
     consequences if a service owner creates a proxy certificate where
     the properties differ from the leaf certificate.  Proxy certificates
can
     be useful in controlled environments, but remain a risk in scenarios
     where the additional flexibility they provide are not necessary.  For
     this reason,  delegated credentials have very restricted semantics
     that should not conflict with X.509 semantics.
[/NS]

Section 3.2

I put this in my PR as essentialy editorial, but copy the change here for
added visibility:

OLD:
  These two mechanisms can be complementary.  A server could use
  delegated credentials for clients that support them, while using
  [KEYLESS] to support legacy clients.  The private key for a delegated
  credential can be used in place of a certificate private key, so it
  is important that the Front-End and Back-End are parties with a
  trusted relationship.

NEW:
  These two mechanisms can be complementary.  A server could use
  delegated credentials for clients that support them, while using a
  server-side mechanism to support legacy clients.  Both mechanisms
  require a trusted relationship between the Front-End and Back-End --
  the delegated credential can be used in place of a certificate
  private key, and the remote key signing case is effectively a signing
  oracle for TLS connections using that certificate.

[NS]
There are some mechanisms that do not devolve into a signing oracle
(such as https://hal.inria.fr/hal-01673853v2) and ideas posed on the
LURK list by EKR (
https://mailarchive.ietf.org/arch/msg/lurk/izHFUkyr8XusOLrB9ZXMq_3G1BY/),
so I propose we don’t include the last part of the sentence you propose.

NEW:
  These two mechanisms can be complementary.  A server could use
  delegated credentials for clients that support them, while using a
  server-side mechanism to support legacy clients.  Both mechanisms
  require a trusted relationship between the Front-End and Back-End --
  the delegated credential can be used in place of a certificate
  private key.
[/NS]

Section 4.1.1, 4.1.2

                           The server MUST ignore the extension unless
  TLS 1.3 or a later version is negotiated.  [...]

How do we feel about DTLS?

          [NS]
          We don’t mention DTLS at all in this draft.  Sean put together a
PR to add it.
          [\NS]

  The expected_cert_verify_algorithm field MUST be of a type advertised
  by the client in the SignatureSchemeList and is considered invalid
  otherwise.  [...]

This is quoted from 4.1.1.) In 4.1.2, the analogous text also
requires the 'algorithm' to be advertised in "signature_algorithms"
(in CertificateRequest in that case).  I think that the same
condition on "signature_algorithms" (in ClientHello) also applies
here (and I proposed that change in my PR).

[NS]
I’m not sure this additional restriction is needed. The client may send
a different list of supported “signature_algorithms” for
the signatures it supports for Certificate keys vs DC keys.  For example,
the client TLS stack may chose to support validating EdDSA signatures by DCs
but only ECDSA for signatures by certificates.  In this case the
“expected_cert_verify_algorithm” would contain but the
“signature_algorithms"
would only contain ECDSA algorithms.  The server would then chose
to send either a ECDSA certificate with no DC, or an ECDSA certificate with
an EdDSA DC.  Requiring an EdDSA algorithm in the ClientHello would
open up the client to receiving an EdDSA certificate, which may not be
supported.
[/NS]

Section 4.2

               The client MUST NOT accept a delegated credential unless
  the server's end-entity certificate satisfies the following criteria:

  *  It has the DelegationUsage extension.

  *  It has the digitalSignature KeyUsage (see the KeyUsage extension
     defined in [RFC5280]).

Should we say anything about (rejecting?) certificates that combine the
DelegationUsage extension with the keyEncipherment KeyUsage implicated in
cross-protocol attacks up in §3?  We talk about ways that server operators
can mitigate this class of attack down in §7.6, but there might be some
options for client behaviors as well (even if those end up just being
"don't advertise support for RSA delegated credentials").

[NS]
It’s tempting, but I don’t think we should say anything here.  There may be
valid
use cases for keyEncipherment that don’t enable cross-protocol attacks in
the
future.
[/NS]

  A new extension was chosen instead of adding a new Extended Key Usage
  (EKU) to be compatible with deployed TLS and PKI software stacks
  without requiring CAs to issue new intermediate certificates.

Are we willing to allocate an EKU that could be used instead of the
DelegationUsage extension?  I hate offering multiple ways to do the same
thing, but if we think that EKU is "the right thing to do", it seems like
we should make it possible to do the right thing, even if we know that it
won't be very feasible right away.

[NS]
I lean towards no.  The implementation issues in how EKUs are enforced
and validated has been problematic for a while, and it’s optimistic to think
that these practical concerns will go away anytime soon.  It might be
cleaner in the abstract to propose an EKU, but it’s likely more practical to
present a single option that is likely to work and be adopted.

I’m open to hearing dissenting opinions from the list.
[/NS]

Section 5

Do we want to say something about how failure to receive an updated
delegated credential prior to expiration of the current one typically will
not cause an outage, since the holder of the credentials will typically
have an existing fallback to remote signing that can be used (albeit at
reduced performance) until the updated delegated credentials becomes
available?

[NS]
At the point an invalid DC is already sent on the connection, it’s too late
to
use the fallback mechanism. Without an attempt to reconnect without
advertising support for DCs, an outage is necessary.  We could explicitly
say “don’t send an expired DC,” but that seems implied.
[/NS]

Section 6

Everywhere in the document other than here, we spell the name of the
extension as "delegated_credential", with no trailing 's'.  IANA has the
's', as instructed by this text.  I don't think it matters which one we
standardize on, but we should pick just one spelling.

Also, as the shepherd writeup notes, we should say that we get
DTLS-OK="Y".

[NS]
This is a typo. We should say “delegated_credential” in the IANA
considerations.
[/NS]

Section 7

We probably want to give some guidance against reusing a given keypair in
DCs that use different expected_cert_verify_algorithms (but I guess reuse
over time for "renewed" DCs of a single sigalg is okay), lest we weaken
the binding between DC and handshake parameters.

[NS]
I’m not sure this is necessary.  We don’t prevent a key pair used in a
certificate
from being signed by multiple CAs with different algorithms.  In fact it
may complicate
deployment scenarios where there is only one DC key in an HSM but multiple
certificates, say ECDSA and RSA
[/NS]

Section 7.1

                                                   An attacker who
  compromises the private key of a delegated credential can act as a
  man-in-the-middle until the delegated credential expires.  [...]

I think this is only true for server delegated credentials.  If I
compromise a client delegated credentials, I still shouldn't be able to
convince the real client that I am the server; I would only be able to
impersonate the client to the server but not act as MITM.

[NS]
Yes, you’re right.

Proposed changes:
NEW
                                                   An attacker who
  compromises the private key of a delegated credential can
  impersonate the compromised party in new TLS connections until the
  delegated credential expires.  [...]
[/NS]

Section 7.4

  If a client decides to cache the certificate chain and re-validate it
  when resuming a connection, the client SHOULD also cache the
  associated delegated credential and re-validate it.

I think we should state the consequences if the client opts to ignore the
SHOULD.

Also, if delegated credentials were used by the client, should the server
perform analogous re-validation?

[NS]
Fair point on revalidation.

Proposed changes:
NEW:
  If a peer decides to cache the certificate chain and re-validate it
  when resuming a connection, they SHOULD also cache the
  associated delegated credential and re-validate it.  Failing to do so
  may result in resuming connections for which the DC has expired.
[/NS]

Nick

---

From: Nick Sullivan <[email-masked]>
Date: Mon, 7 Mar 2022 11:59:30 -0500

FYI, I've put my proposed changes up as a PR:
https://github.com/tlswg/tls-subcerts/pull/98

Nick

On Tue, Mar 1, 2022 at 10:22 AM Nick Sullivan <[email-masked]> wrote:

> It’s tempting, but I don’t think we should say anything here.  There may
> be valid
> At the point an invalid DC is already sent on the connection, it’s too
> late to

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Mar 2022 23:34:31 -0700

Hi Nick,

In full turnaround I of course failed to see *your* mail as it came in; my
apologies.

tl;dr: the now-posted -12 is good enough for me to initiate IETF LC.
Some additional notes inline.

> holder.  I don’t think there’s a useful change we can make that improves

That makes sense to me as a reason for this section to be specific to
server DC usage.

> so I propose we don’t include the last part of the sentence you propose.

Not a generic signing oracle, yes.  But it's still signing TLS
CertificateVerify for the edge server and is an "oracle" in that limited
sense.

>   the delegated credential can be used in place of a certificate

That said, this text is probably fine.

> open up the client to receiving an EdDSA certificate, which may not be

(To be clear, it seems that my PR got merged with the condition on
"signature_algorithms" included, so the -12 has the restriction on
usable algorithms needing to have been in "signature_algorithms" for both
client and server authentication.)

This feels reminiscent about the motivation for making distinct
"signature_algorithms" and "signature_algorithms_cert", with the assumption
that a TLS stack itself would have uniform support for using a given
algorithm for signing TLS objects even if its X.509 stack has different
limitations for what signatures on certificates can be processed.  The term
"an EdDSA certificate" is not very precise in this regard (signature on the
certificate uses EdDSA vs the key being certified is EdDSA) so I am not
sure if you still see an issue not resolvable by sending distinct
"signature_algorithms" and "signature_algorithms_cert" extensions.

> say “don’t send an expired DC,” but that seems implied.

Hmm, I think my message may have been garbled here.
Basically, you can't assume all clients support DCs, so if you are a
general-purpose server and want to use DCs, you need some provision for
clients that don't support DCs.  If you are such a server and have a DC,
but its expiration approaches and you keep failing to get a "renewed" DC,
rather than serving the expired/expiring DC to clients that support DCs,
you would just pretend to not support DCs and use the "fallback" mechanism
for all clients.  So it seems like the server would not experience a
complete DoS on DC expiration (though in the context of a single connection
I agree with you).

> certificates, say ECDSA and RSA

I'm not sure if I'm confused here or not (it's been a while since I first
wrote the comment).  My understanding is that the "expected_cert_verify"
algorithm is a TLS SignatureScheme codepoint value that corresponds to the
signatures that will be produced by the private key that corresponds to the
public key in the Credential object.  So it should be completely disjoint
from the certificate used to sign the Credential.  I think I was just
trying to say "don't use a single DC private key to make different types of
signatures" on the general grounds of "only use a given key for a single
type of operation".  In this case in particular, if multiple Credentials
exist that have the same public key but different
expected_certifiate_verify_algorithms, it seems like that opens up some
malleability for an attacker or malicious DC holder that wants to confuse
the peer receiving the DCs about what operations have been performed.  I'm
pretty sure there's no actual concrete attack just from the different DCs
existing, but it feels like giving rope to the attacker and I don't see
much justification for allowing it.

The rest of the changes look good.

Thanks,

Ben