[TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

[Viktor Dukhovni <[e-mail]>]

TL;DR:  Should TLS client abort DHE-RSA handshakes with a peer
certificate that *only* lists:

            X509v3 Key Usage: 
                Key Encipherment, Data Encipherment

(which one might take to mean that only RSA key exchange is allowed,
and DHE-RSA is not, for lack of the DigitalSignature bit?

[ In the unlikely case it matters, the record the certificate
  in question is self-signed, and has a DANE TLSA "3 0 1" record. ]

-- Background:

I am somewhat sympathetic to forbidding RSA key exchange when
"Key Encipherment" is not listed, in order to reduce the risk of
Bleichenbacher-type attacks, but it is not obvious at first blush
why one might the converse restriction...

The reason I ask is that the Haskell TLS library has recently added
enforcement in both directions, and I am finding some SMTP servers
with whose STARTTLS implementation my DANE scan engine no longer
interoperates.

And yet, FWIW, OpenSSL 1.1.1 continues to connect just fine.  Is
this an oversight in OpenSSL?  Overly strict enforcement in Haskell's
Network.TLS?  Should the language in RFC8446 apply also to TLS 1.2
and earlier, where no mention of "keyUsage" is to be found in the
relevant specifications?

The text in 8446 is not crystal clear on the intent.  Is keyUsage
enforcement (absent OID filters from the peer) a MUST?  A SHOULD?
A BCP?  And which directions should it apply in?  That is, does
it make sense to require RSA key transport when DHE appears to
be disallowed?

In appendix E.8 of TLS 1.3 RFC8446 <https://tools.ietf.org/html/rfc8446#appendix-E.8
>
we find:

   E.8.  Attacks on Static RSA

   Although TLS 1.3 does not use RSA key transport and so is not
   directly susceptible to Bleichenbacher-type attacks [Blei98], if TLS
   1.3 servers also support static RSA in the context of previous
   versions of TLS, then it may be possible to impersonate the server
   for TLS 1.3 connections [JSS15].  TLS 1.3 implementations can prevent
   this attack by disabling support for static RSA across all versions
   of TLS.  In principle, implementations might also be able to separate
   certificates with different keyUsage bits for static RSA decryption
   and RSA signature, but this technique relies on clients refusing to
   accept signatures using keys in certificates that do not have the
   digitalSignature bit set, and many clients do not enforce this
   restriction.

In 4.2.5 <https://tools.ietf.org/html/rfc8446#section-4.2.5> we
also find:

   This document defines matching rules for two standard certificate
   extensions defined in [RFC5280]:

   -  The Key Usage extension in a certificate matches the request when
      all key usage bits asserted in the request are also asserted in
      the Key Usage certificate extension.

But that's about explicit OID filters from the peer, not a-priori
constraints.

-- 
	Viktor.