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 <[email protected]> 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 <[email protected]> wrote: > >> >> >> On Fri, Mar 20, 2020 at 9:23 AM Nimrod Aviram <[email protected]> >> 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 <[email protected]> >>> Date: Fri, 20 Mar 2020 at 01:21 >>> Subject: Re: [TLS] Delegated Credentials: The impact of a hypothetical >>> Bleichenbacher attack >>> To: Nimrod Aviram <[email protected]> >>> Cc: <[email protected]> <[email protected]>, Juraj Somorovsky < >>> [email protected]> >>> >>> >>> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
