azathoth.unzane.com: DANE TLSA record misconfiguration

[Gerald Turner]

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 <gturner at unzane.com>        Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: <https://mail.sys4.de/pipermail/dane-users/attachments/20181203/b26221f0/attachment.asc>