azathoth.unzane.com: DANE TLSA record misconfiguration

[Viktor Dukhovni]

On Mon, Dec 03, 2018 at 12:19:18PM -0800, Gerald Turner wrote:

> >     ; 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.

You're welcome.

> 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.

Yes, the same "3 1 2" record has been in place since at least "Thu
Oct 19 23:12:23 EDT 2017", when I cut over from SQLite3 to Postgres.

> 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.

The survey engine encountered a new leat certificate on "Sat Dec
1 21:38:02 EST 2018", that no longer matched the TLSA record.

> 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.

In such configurations, you MUST publish separate TLSA records for
each algorithm.  Even if your server consistently prefers one
algorithm over the other, some clients might support only RSA or
only ECDSA.  And if (as you *really* SHOULD) you follow the advice
from the ICANN slides, and publish TLSA records to match both the
"current" and "next" key, then you again need to do that twice:

    _25._tcp.mx.example.com. IN TLSA 3 1 1 <curr-rsa-key-sha256>
    _25._tcp.mx.example.com. IN TLSA 3 1 1 <next-rsa-key-sha256>
    _25._tcp.mx.example.com. IN TLSA 3 1 1 <curr-ecdsa-key-sha256>
    _25._tcp.mx.example.com. IN TLSA 3 1 1 <next-ecdsa-key-sha256>

(or perhaps three times..., if you also support ed25519).

> 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.

Good.  But I think you have too many TLSA records now:

    unzane.com. IN MX 10 azathoth.unzane.com. ; AD=1 NoError
    azathoth.unzane.com. IN A 184.105.220.20 ; AD=1 NoError
    azathoth.unzane.com. IN AAAA 2001:470:e861:2::2 ; AD=1 NoError
    _25._tcp.azathoth.unzane.com. IN CNAME azathoth-ta-ee-dual._tlsa.unzane.com. ; AD=1 NoError

So far so good, but, why four "2 1 1" records?  Pick either the
intermediate or the root, no need to cover them all.

    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 1 27d7a8ff7fdff07c3329a09690dda74cd65b58103f67564fe0f837b6f50aa485 ; AD=1 NoError
    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 1 3f7380de4d9612e3fa4a143cb27d7d426ae669a4f2f36c72a8b22a190d353f95 ; AD=1 NoError
    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 1 7510f3f1e79d6c1ed06e695b050ceedc6e5a8c24609228bc09b2ec86c743f939 ; AD=1 NoError
    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 1 99ef1b3ce5f5755e815759959488f8dd59c7cc17326484a83f37526817aa78f8 ; AD=1 NoError

And use only "2 1 1" or "2 1 2", whichever you prefer, but "2 1 1"
is more than secure enough, and makes for smaller DNS packets, so
drop all the "2 1 2" records.

    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 2 51df1093ea3e1a2302f05cee6d6f4df574a4ff60efeefcf440a84d941beb157f7e520d3854b09ee7c1f07e27280d7163c6db8b1bd547a704e9e93bc0513fe03b ; AD=1 NoError
    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 2 651268a16b36fc4e721287b8a627ab802c2d7bae982e00ccf8e5e5677a32dd947381729663d6b606fadb8f9c89d62f33d574a7a42c9413e5f137c33e5583fab4 ; AD=1 NoError
    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 2 6ea9483eece1b61ac70efa6e66f64543e928000ddf264c5f6ce0d0ec1be0948840461255f178b8bed6f915b0579550961dd8739f4ec380c628f164172f7cbb86 ; AD=1 NoError
    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 2 1 2 f4275dc6cadb1faf52c4397110de636aaa04e0b85762ff7f2740b0583dcb14976f93e8f55a4a795068608673c8f5469aae007ed20c11856ce4cd597828cbc5a8 ; AD=1 NoError

And finally we see two 3 1 1 records, presumably one for RSA and
another for ECDSA.  Again drop the "3 1 2", but if you really feel
more vigour in your step by publishing "3 1 2", then drop "3 1 1".
No need to publish both.

    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 3 1 1 69588ebf0bf87d04fe24ff9f6b0104ee35a0d788cccb0ac90361492aa6711a27 ; AD=1 NoError
    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 3 1 1 ab1050b29bfa92cb69a2d3c4d9836cf984120131a0d48783deb9fee4031ec43c ; AD=1 NoError
    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 3 1 2 77cebe0d37187c0ad490de5f97b329ea6488e20f8a166d6fea3949a1555fbc8dd6f39d6f16bdf2858f2bc0de22c11de709232c6e687e3e45bd814ea8e4ad46eb ; AD=1 NoError
    azathoth-ta-ee-dual._tlsa.unzane.com. IN TLSA 3 1 2 ee8dad1abbb174615af798cf240f044ee176e4a761bd156e2adc2aa496b7a315af1c5b04ff8ba3fe48a4457f87bded23c5d76a3c8743040b9d69ff302046f768 ; AD=1 NoError

The chain matches both "X 1 1" and "X 1 2" at every depth, but has
a rather odd "Organization" value (shouwn in hex U+ABCD notation):

      azathoth.unzane.com[184.105.220.20]: pass: TLSA match: depth = 0, name = azathoth.unzane.com
	TLS = TLS12 with ECDHE-ECDSA-AES256GCM-SHA384
	name = azathoth.unzane.com
	name = mail.unzane.com
	depth = 0
	  Issuer CommonName = Unzane Intermediate Certificate Authority (ECDSA)
	  Issuer Organization = U+1F184 U+1F17D U+1F189 U+1F170 U+1F17D U+1F174
	  notBefore = 2014-04-07T17:27:00Z
	  notAfter = 2038-01-19T03:14:07Z
	  Subject CommonName = azathoth.unzane.com
	  pkey sha256 [matched] <- 3 1 1 ab1050b29bfa92cb69a2d3c4d9836cf984120131a0d48783deb9fee4031ec43c
	  pkey sha512 [matched] <- 3 1 2 77cebe0d37187c0ad490de5f97b329ea6488e20f8a166d6fea3949a1555fbc8dd6f39d6f16bdf2858f2bc0de22c11de709232c6e687e3e45bd814ea8e4ad46eb
	depth = 1
	  Issuer CommonName = Unzane Certificate Authority (ECDSA)
	  Issuer Organization = ...
	  notBefore = 2014-04-07T17:27:00Z
	  notAfter = 2038-01-19T03:14:07Z
	  Subject CommonName = Unzane Intermediate Certificate Authority (ECDSA)
	  Subject Organization = ...
	  pkey sha256 [matched] <- 2 1 1 99ef1b3ce5f5755e815759959488f8dd59c7cc17326484a83f37526817aa78f8
	  pkey sha512 [matched] <- 2 1 2 51df1093ea3e1a2302f05cee6d6f4df574a4ff60efeefcf440a84d941beb157f7e520d3854b09ee7c1f07e27280d7163c6db8b1bd547a704e9e93bc0513fe03b
	depth = 2
	  Issuer CommonName = Unzane Certificate Authority (ECDSA)
	  Issuer Organization = ...
	  notBefore = 2014-04-07T17:27:00Z
	  notAfter = 2038-01-19T03:14:07Z
	  Subject CommonName = Unzane Certificate Authority (ECDSA)
	  Subject Organization = ...
	  pkey sha256 [matched] <- 2 1 1 3f7380de4d9612e3fa4a143cb27d7d426ae669a4f2f36c72a8b22a190d353f95
	  pkey sha512 [matched] <- 2 1 2 651268a16b36fc4e721287b8a627ab802c2d7bae982e00ccf8e5e5677a32dd947381729663d6b606fadb8f9c89d62f33d574a7a42c9413e5f137c33e5583fab4

> 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 because of the green
> highlighted row "3, 1, 2 ee8dad1abbb17461[...]9d69ff302046f768" was the
> RSA record that had existed prior to the fixes.

Yes, "dane.sys4.de" prefers RSA, while my survey scan engine prefers
ECDSA.  Good to have more than one perspective.

-- 
	Viktor.