Hi Nick, Thank you again for the detailed explanation. We agree with your preference for option 1. Would it help if I contribute a draft of the new text for the security considerations section?
best wishes, Nimrod On Fri, 20 Mar 2020 at 18:57, Nick Sullivan <n...@cloudflare.com> wrote: > > > On Fri, Mar 20, 2020 at 9:23 AM Nimrod Aviram <nimrod.avi...@gmail.com> > wrote: > >> 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? >> > > This doesn't stop the attack, it just reduces the probability that a new > oracle will be exploitable in servers that implement DCs. If the oracle > exists in existing legacy servers where the cert is used, it doesn't matter > what DC-enabled servers do. Removing support for TLS-RSA in TLS 1.2 is a > valid TLS policy choice for today's age, but enforcing it in the protocol > document doesn't improve the security versus known attacks like DROWN. > Requiring EC keys for DC-enabled certificates is also an artificial > limitation that should be avoided -- not all CAs support EC certs and not > all software supports EC code. > > What you really want is to prevent keys from being used across different > contexts. I see two options for this: > > 1) Add strong wording in the security considerations section about how it > is dangerous to use the same key in different contexts. Advise implementers > to use DC-enabled certificates only for signing DCs, not for terminating > TLS or SSL -- if their software allows it. > 2) Enforce on the client-side that DC-enabled certificates can only be > used for DC handshakes. This option prevents DC certificates from being > used in an DC-capable server by DC-enabled clients, but it doesn't prevent > the certificate from being deployed on legacy services exposing an oracle. > The downside of this restriction is that it adds complexity for server > implementations (need the ability to load certificates dynamically based on > client hello), and operators (two certificates need to be managed per > service, not just one). > > My preference is for 1) > > >> 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
