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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Jan 2022 19:01:37 -0800

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.

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.

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".

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.

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.

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?

   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).

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").

   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.

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?

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".

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.

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.

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?

Thanks,

Ben