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

[Nimrod Aviram <[e-mail]>]

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