On Thu, Aug 31, 2017 at 07:36:10AM +0000, Carsten Strotmann wrote:
Below a little text about TLS certificate agility and some pitfalls herein (thanks to Viktor and Patrick for input and review):
Thanks for this post. Just wanted to mention that the concern about TLSA records matching only the RSA certificate chain and not the ECDSA certificate chain of an MX host is not just "theoretical".
I've so far found two MX hosts of live domains that have both RSA and ECDSA chains deployed, but the TLSA records match only the RSA chain. As more users get adventurous and start deploying ECDSA, this problem is likely to become more frequent, if we don't manage to raise awareness. So this thread is a first step in that direction.
A new (improved :-)) DANE scanner I've written in Haskell (the old one is in Perl) prefers ECDSA over RSA, and so is starting to find the misconfigured MX hosts that are missing the TLSA RRs needed to match the ECDSA chain.
Don't forget that even "3 1 1", which matches only the public key and not the full certificate, still won't match both an RSA and an ECDSA server certificate, as, of course, the RSA and ECDSA public keys are different (not only in the raw key bits, but also in the ASN.1 OIDs that indicate the key type, the DANE TLSA public key hash covers not only the key and any key parameters, but also the key type OID).