Hi Nick, Thank you for the detailed response!
In light of your explanation, we are curious why high-profile servers using Delegated Credentials need to support TLS-RSA? Most of the relevant clients (or all of them?) support ephemeral key exchange in TLS. So would it be possible to improve the state-of-the-art by forbidding TLS-RSA and demanding correct keyUsage, at least in such high-profile scenarios? Assuming this is not possible, we agree with your conclusion. It looks like the second alternative is more effective - to discourage the use of DC-enabled certificates in contexts where an oracle may be present. One possible defense-in-depth is to use DC only with EC certificates. best wishes, Robert, Juraj and Nimrod ---------- Forwarded message --------- From: Nick Sullivan <n...@cloudflare.com> Date: Fri, 20 Mar 2020 at 01:21 Subject: Re: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack To: Nimrod Aviram <nimrod.avi...@gmail.com> Cc: <tls@ietf.org> <tls@ietf.org>, Juraj Somorovsky <juraj.somorov...@upb.de > Hello Nimrod, Robert and Juraj, Thank you for the report! The fact that a single signature oracle computation can be used to create a DC and therefore intercept multiple connections for up to 7 days is something we considered when writing this specification. The mitigation you proposed in option 1 (requiring the keyEncipherment KeyUsage to not be present on DC-capable certificates) is sound in theory, but unlikely to be effective in practice since many servers (including many of the ones identified in DROWN) ignore the requirement that keyEncipherment KeyUsage is present. Stating this requirement in the text of this document is unlikely to prevent existing oracles from being leveraged if the certificate is used in multiple contexts and is likely to introduce complexity on the CA side, so I'm inclined not to include this requirement. I'd be happy to hear an argument to the contrary, though. I'm more inclined to incorporate some text into the security considerations to discourage the use of DC-enabled certificates in contexts where an oracle may be present. Servers may even go as far as to use a different certificate for DC-enabled handshakes vs regular handshakes --- although very few servers support this sort of dynamic certificate switching in practice so it would be difficult to make a hard requirement here. Nick On Thu, Mar 19, 2020 at 6:08 AM Nimrod Aviram <nimrod.avi...@gmail.com> wrote: > Hi folks, > > We're writing to ask (and share some concerns) about the potential impact > of a Bleichenbacher attack when delegated credentials are in use. > > This issue is already discussed in the standard: > In 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.) > ``` > > And 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]). > ``` > > Currently, it seems the standard does not discuss the common situation > where the certificate has both the digitalSignature and keyEncipherment > KeyUsages. > If we understand correctly, for such certificates using Bleichenbacher's > attack to forge a single signature once over a delegated credential, > would grant an attacker the equivalent of a man-in-the-middle certificate. > Section 3 mentions SSLv2, and this protocol indeed enabled a severe form > of Bleichenbacher's attack, but these attacks are not limited to older > protocol versions. > There have been implementations of TLS 1.2 vulnerable to Bleichenbacher's > attack, even by server operators as competent as Facebook, as discussed > e..g. in the ROBOT paper. > > Also, coming back to SSLv2, one problem at the time was that the > recommended way to disable SSLv2 in OpenSSL did not in fact disable > SSLv2. Administrators who followed the guidelines falsely assumed they > had disabled the protocol, but had no way to verify it was disabled. It > would be prudent to assume this may happen again, e.g. administrators will > be unaware that they have obsolete or vulnerable cryptography enabled. > > In light of the above, we would recommend one of two alternatives: > 1. Change the text in Section 4.2 to say "[the certificate] has the > digitalSignature KeyUsage, and does not have the keyEncipherment KeyUsage. > Furthermore, the certificate does not share its public key with any > certificate that has the keyEncipherment KeyUsage." > - or - > 2. Add text in the Security Considerations Section explaining that: > 2.1. The recommended way for server operators to defend in depth against > this type of attack is to use a certificate as in alternative 1 with > delegated credentials. > 2.2. Absent that, server operators should be aware of this risk. > > We would be happy to continue the discussion and help in any way. > > best wishes, > Juraj, Robert and Nimrod > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
