Hello Viktor, [CC'ing dane-users list to mea culpa to the Internet at large, appreciate any advice ;-)]
On Mon, Dec 03 2018, Viktor Dukhovni wrote: > Your TLSA RRset does not match the actual certificate chain of some > of your MX hosts. It is better to have no TLSA records than to > have incorrect TLSA records. Please adopt a *better* key rotation > approach, what you're doing now is fragile and DOES NOT work reliably. > > Suggested more robust TLSA record management approaches are described > in slides presented at the ICANN61 conference in March of 2018: > > http://imrryr.org/~viktor/ICANN61-viktor.pdf > http://imrryr.org/~viktor/icann61-viktor.mp3 > > The relevant DNS records are: > > ; DANE TLSA fail > ; None of the TLSA records match the certificate chain > ; > _25._tcp.azathoth.unzane.com. IN CNAME azathoth-rsa._tlsa.unzane.com. > azathoth-rsa._tlsa.unzane.com. IN TLSA 3 1 2 > ee8dad1abbb174615af798cf240f044ee176e4a761bd156e2adc2aa496b7a315af1c5b04ff8ba3fe48a4457f87bded23c5d76a3c8743040b9d69ff302046f768 > > Affected domains: > > unzane.com. IN MX 10 azathoth.unzane.com. Thank you for informing me of this misconfiguration at my site. I'm curious whether your DANE validation scans had found my mail server to validate successfully in the past, prior to Saturday December 1st, 8:20AM PST. Coincidentally this is time that the OpenSSL package within Debian stable/security-updates archive had been upgraded on this server, from version 1.1.0f-3+deb9u2 to version 1.1.0j-1~deb9u1. This upgrade triggered SMTP STARTTLS monitoring alarms (using Monit, checking fingerprints), which I had rectified, however I had neglected the impact to DANE. For whatever forgotten reason, the x509 certificates for this site are "dual stacked", one set of certificates for RSA, and another set of certificates for ECDSA. Postfix had been configured to support both chains of certificates (smtp_tls_cert_file + smtp_tls_eccert_file). To my surprise, the minor OpenSSL version bump must have changed cipher suite order and caused the ECDSA flavor to be served. I read your ICANN61 slides (very nice, BTW), and tried the Bash/OpenSSL DANE check function at the end. Appending openssl s_client option "-cipher 'HIGH:-ECDHE'" causes the check to pass. Nevertheless, I've updated our TLSA records to include the ECDSA flavor. Check now passes with or without the explicit cipher suites hack. Although I missed the opportunity to run your DANE/SMTP web validator¹ prior to updating my TLSA records, FWICT it looks like the web validator is using RSA flavor connections, thus would have passed prior to fixing the TLSA records for ECDSA flavor. Guessing here becuase of the green highlighted row "3, 1, 2 ee8dad1abbb17461[...]9d69ff302046f768" was the RSA record that had existed prior to the fixes. ¹ https://dane.sys4.de/smtp/unzane.com -- Gerald Turner <[email protected]> Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D
signature.asc
Description: PGP signature
