Greetings!
Our this year's Christmas gift to the community is a service that let’s you
monitor and detect typical DANE related problems for DANE-enabled inbound SMTP
services. You can integrate the service in your own service environment or run
it as a docker container and poll it for test results from a monitoring service.
## Why?
We believe every platform should enable and use DANE. DANE is the missing
piece in TLS or as Wietse Venema once put it: „Encryption without
authentication is not 'security'. It just gives some privacy.“ DANE adds the
missing authentication bit. But DANE enforces strict policy and if your
platform fails inbound DANE-verification you will not receive email from those
platforms that enforce outbound DANE-verification. A failing DANE policy
imposes a production risk.
## Why would your platform fail DANE verification?
From discussions with Viktor about the statistics he generates at
<https://stats.dnssec-tools.org/#/> we know that in most cases, when
DANE-enabled platforms fail DANE-verification, it is because the published
TLSA resource record(s) in DNS do not match one of the x509 certificate's
fingerprint.
We want everybody to benefit from the security DANE adds to TLS and not have
people look at it as a production risk! This is why we built the SMTP DANE
Verify service. It will test and detect common DANE policy problems. Using
SMTP DANE Verify everybody will be able to monitor their own (and other)
domains and raise an alarm in case the tested domain fails DANE verification.
## How would you use SMTP DANE Verify?
If you think SMTP DANE Verify is for you check out the project at
<https://github.com/sys4/smtp-dane-verify>. The project's README should give you
all the information you need to setup, run and integrate SMTP DANE Verify on
your platform.
On a sidenote: In case you are still in doubt if anyone should be using DANE at
all: the EU has launched a Multi-Stakeholder Working Group for Internet
Standards in the EU and DANE is a major item on the groups roadmap. Follow this
link to read more:
<https://digital-strategy.ec.europa.eu/en/news/european-commission-seeks-par…>
And that's it! We hope you will find it as useful as we do. Season greetings
to all of you. Peace on earth to all of us. o:)
p@rick
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
It appears that starting a couple of days ago, newly issued/renewed
Let's Encrypt (LE) certificates will be signed by R12, R13, E7 and E8,
rather than the previously active R10, R11, E5 and E6. See the
announcement at:
https://community.letsencrypt.org/t/switching-issuance-to-new-intermediates…
and the associated advice on the DANE survey site:
https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html
Of course everyone who includes LE issuer CA public key or cert hashes
in their TLSA records should already be covered by including all of
R10-R14 and/or E5-E9, but sadly many are not, because the DANE survey
shows that the MX host counts for the various LE CAs are skewed in
favour of the previously active issuers:
# | CA
-----+-----
63 | X3 -- Long obsolete should not be used
12 | X4 -- Long obsolete should not be used
370 | R3 -- Long obsolete should not be used
119 | R4 -- Long obsolete should not be used
116 | E1 -- Long obsolete should not be used
91 | E2 -- Long obsolete should not be used
773 | E5
803 | E6
392 | E7
391 | E8
382 | E9
813 | R10
806 | R11
466 | R12
469 | R13
462 | R14
608 | ISRG X1 root
246 | ISRG X2 root
If you still want to rely on TLSA records tied to the LE issuers, and
haven't published the appropriate full set of hashes, better late than
never. You'll need to do so now. And of course you'll need to keep up
with the news from LE and make additional timely changes in the future
as the CAs used by LE evolve.
--
Viktor. 🇺🇦 Слава Україні!
