Re: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack

[Nimrod Aviram <[e-mail]>]

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 <[e-mail]> wrote:

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