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

From: Nimrod Aviram <[email-masked]>
Date: Thu, 19 Mar 2020 13:16:42 +0200

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

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 19 Mar 2020 16:19:07 -0700

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-masked]>
wrote:

> e..g. in the ROBOT paper.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nimrod Aviram <[email-masked]>
Date: Fri, 20 Mar 2020 18:23:36 +0200

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 <[email-masked]>
Date: Fri, 20 Mar 2020 at 01:21
Subject: Re: [TLS] Delegated Credentials: The impact of a hypothetical
Bleichenbacher attack
To: Nimrod Aviram <[email-masked]>
Cc: <[email-masked]> <[email-masked]>, Juraj Somorovsky <[email-masked]

Nick

---

From: Nick Sullivan <[email-masked]>
Date: Fri, 20 Mar 2020 09:54:57 -0700

On Fri, Mar 20, 2020 at 9:23 AM Nimrod Aviram <[email-masked]>
wrote:

> 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

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
> Cc: <[email-masked]> <[email-masked]>, Juraj Somorovsky <
> [email-masked]>
>
>
> 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
> 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
>

---

From: Nimrod Aviram <[email-masked]>
Date: Fri, 20 Mar 2020 20:12:11 +0200

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-masked]> wrote:

> 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
>> 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

---

From: Nick Sullivan <[email-masked]>
Date: Fri, 20 Mar 2020 11:43:23 -0700

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-masked]>
wrote:

>>> 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
>>>
>>> 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

---

From: Nimrod Aviram <[email-masked]>
Date: Tue, 24 Mar 2020 14:26:50 +0200

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 <[email-masked]> wrote:

>>> 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.
>>>> 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