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