Hi Nick, thanks! I sent a PR here: https://github.com/tlswg/tls-subcerts/pull/60
best wishes, Nimrod On Fri, 20 Mar 2020 at 20:45, Nick Sullivan <n...@cloudflare.com> wrote: > Hi Nimrod, > > This is a working group document, so it's open to comments and suggestions > from anyone in the IETF community. Feel free to send a PR > https://github.com/tlswg/tls-subcerts and we can discuss on-list. > > Nick > > On Fri, Mar 20, 2020 at 11:12 AM Nimrod Aviram <nimrod.avi...@gmail.com> > wrote: > >> 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
