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 <n...@cloudflare.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
