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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
