January 2024 - dane-users

Best to not outright refuse non-TLS incoming mail...
by Viktor Dukhovni 11 Oct '24

11 Oct '24

The DANE survey (https://stat.dnssec-tools.org) turns up a few domains a day that botch their cert rollovers or fail to offer STARTTLS despite publishing DANE TLSA records. I try to send notices to the relevant contacts, but sometimes they shoot themselves in the foot: - Private WHOIS - No contact data at the website - Published contacts don't work (no such user, ...). - Reject earnest notices of technical problems as spam Yesterday, for the first time, I ran into someone whose MTA stopped offering STARTTLS, despite the TLSA records still being in place, but attempts to deliver a notice are rejected: posttls-finger: < 220-mail.<censored>.dk ESMTP Postcow ... brief pause... posttls-finger: < 220 mail.<censored>.dk ESMTP Postcow posttls-finger: > EHLO <...> posttls-finger: < 250-mail.<censored>.dk posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 104857600 posttls-finger: < 250-ETRN posttls-finger: < 250-AUTH PLAIN LOGIN CRAM-MD5 posttls-finger: < 250-AUTH=PLAIN LOGIN CRAM-MD5 posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250-DSN posttls-finger: < 250 CHUNKING posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye The notice bounced with: 550 5.7.1 Session encryption is required (in reply to RCPT TO command) As commendable as it may be to encourage use of TLS, it is not a good practice to outright refuse cleartext mail. -- Viktor.

4 3

DANE monitoring building block: "danesmtp" shell function
by Viktor Dukhovni 04 Sep '24

04 Sep '24

As you're may be aware, I actively promote adoption of DANE SMTP, many thanks to everyone who's moved forward with DANE SMTP deployment! That said, I also always stress that, when deploying DANE SMTP, *monitoring* must come first, and publishing of DANE TLSA records second. If your DANE TLSA deployment is unmonitored, it will some day fail, with you being the last to know that something is wrong when some email fails to arrive on time or at all. Unmonitored security is a ticking time-bomb. Please implement monitoring of your DANE TLSA records vs. the live certificate chain through regular probing of your MX hosts (I'd suggest hourly if not more often for more critical servers). Of course you also need to have good automation of the certificate rollover process so that normally TLSA records aren't out sync with the certificates even during a rollover. If you don't yet have monitoring in place, the below could be a useful building block for your monitoring scripts. The "danesmtp" shell (bash) function can take an optional explicit IP address to connect to, so you can test each of the IP addresses of a host in turn: danesmtp () { local OPTIND=1 opt local -a rrs sslopts local rr i=0 host addr while getopts a: opt; do case $opt in a) addr=$OPTARG case $addr in *:*) addr="[$addr]";; esac;; *) printf 'usage: danesmtp [-a addr] host [ssloption ...]\n' return 1;; esac done shift $((OPTIND - 1)) host=$1 shift if [[ -z "$addr" ]]; then addr="$host" fi sslopts=(-starttls smtp -connect "$addr:25" -verify 9 -verify_return_error -dane_ee_no_namechecks -dane_tlsa_domain "$host") rrs=( $(dig +short +nosplit -t tlsa "_25._tcp.$host" | grep -Ei '^[23] [01] [012] [0-9a-f]+$') ) while (( i < ${#rrs[@]} - 3 )); do rr=${rrs[@]:$i:4} i=$((i+4)) sslopts=("${sslopts[@]}" "-dane_tlsa_rrdata" "$rr") done ( sleep 1; printf "QUIT\r\n" ) | openssl s_client -brief "${sslopts[@]}" "$@" } -- Viktor.

4 7

TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain
by Viktor Dukhovni 10 Jun '24

10 Jun '24

The DANE/DNSSEC survey (<https://stats.dnssec-tools.org>) has seen a recent spike in the number of MX hosts whose "2 1 1" TLSA records no longer match their certificate chain. The records in question all shar the same digest value, for various TLSA base domains: _25._tcp.mx1.example. IN TLSA 2 1 1 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 I was initially puzzled as to why this might be happening, but then it occurred to me that the reason why is clear. The above hash is the hash of the ISRG X1 root CA key, but it is also of course the key hash of its outdated **cross-certificate** issued by DST. That DST cross cert was needed for compatability with some old Android systems that did not get root CA updates (or updates of any kind). It must be that Let's Encrypt finally stopped by default including that cross certificate in their chains. So instead of a chain that looks like: - depth 0: EE (server) certificate - depth 1: Let's Encrypt R3/E1 issuer CA - depth 2: ISRG X1 cross cert issued by DT with the certificate at depth 2 matching the TLSA record, they now generate just: - depth 0: EE (server) certificate - depth 1: Let's Encrypt R3/E1 issuer CA with the ISRG (now standalone) root CA not included in the chain! Leaving out the root CA works fine for WebPKI, where clients need to have a locally trusted copy of the root, but not for certificate usage DANE-TA(2), which does not rely on any local CA store: https://dane.sys4.de/common_mistakes#4 https://datatracker.ietf.org/doc/html/rfc7672#section-3.1.2 Bottom line, if you're relying on that "2 1 1" record matching the ISRG root to match your Let's Encrypt chain, you're about to be disappointed, if you aren't already. See: http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html for better alternatives, or switch to "3 1 1", perhaps with the aid of "danebot" (still hoping some early adopters will pitch in to further improve it, to support some additional workflows): <https://github.com/tlsaware/danebot> -- Viktor.

2 6