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. On Tue, Mar 01, 2022 at 10:22:03AM -0500, Nick Sullivan 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] That makes sense to me as a reason for this section to be specific to server DC usage. > 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. 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. > 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] That said, this text is probably fine. > 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] (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. > 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] 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). > 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] > 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 > 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
