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 [email protected] https://www.ietf.org/mailman/listinfo/tls
