On 11/05/2018 06:58 PM, Viktor Dukhovni wrote:
I've recently come across an interoperability problem between my
DANE survey scan engine and some STARTTLS implementations on remote
SMTP servers. The issue resulted from an upgrade of the TLS library
(not OpenSSL, which does not seem to mind) on my side, which introduced
more strict checking of the certificate "keyUsage" extension.
This seems to be intended to address Bleichenbacher-style attacks
on the legacy RSA key exchange mechanism which performs "Key
Encipherment", while these days the preferred mechanism is
DHE or ECDHE which uses the certificate for "DigitalSignature".
There is no mention of enforcing keyUsage constraints in TLS RFCs,
prior to TLS 1.3 (RFC 8446 appendix E.8) and even there there is
not a clearly stated requirement to perform such enforcement.
So there's no need to "panic", but I though I'd mention that
your certificates should probably either not set "keyUsage"
at all, or if they do, it makes more sense to rule out
RSA key transport, rather than restrict oneself to it.
Therefore, make sure your certificate (not extended)
keyUsage is either not there at all, or perhaps
specifies:
keyUsage = digitalSignature
and perhaps not "keyEncipherment" (RSA key transport).
if not using keyUsage but using extendedKeyUsage within req_extensions
should digitalSignature be used?
I basically do the following for my postfix certs
[req]
distinguished_name = dn
req_extensions = ext
prompt = no
[dn]
CN = ${FQDN}
[ext]
basicConstraints = critical,CA:FALSE
extendedKeyUsage = serverAuth,clientAuth
subjectAltName = @san
(obviously with any alternate names in [san]
-=-
I'm also under the impression that the basicConstraints likey isn't
necessary because CA:FALSE is assumed when not specified. Is that true?
