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