June 2024 - dane-users - list.sys4.de

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

12 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 05 Sep '24

05 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

Microsoft inbound DANE live
by Viktor Dukhovni 22 Jun '24

22 Jun '24

Microsoft's inbound DANE service is showing signs of life: https://x.com/VDukhovni/status/1804324326633783696 The first two customers appear to be the Danish Defence Intelligence Service and the Czech Office for Personal Data Protection! https://stats.dnssec-tools.org/explore/?ddis.dk https://stats.dnssec-tools.org/explore/?fe-ddis.dk https://stats.dnssec-tools.org/explore/?fe-mail.dk https://stats.dnssec-tools.org/explore/?uoou.cz Looking forward to many more... -- Viktor.

1 0

samba.org
by Erwin Hoffmann 16 Jun '24

16 Jun '24

Hi, could somebody pls check ns1.samba.org? (from list.samba.org) I get strange results here. smtp.samba.org is just fine. Thanks and regards. --eh. -- Dr. Erwin Hoffmann | www.fehcom.de PGP key-id: 20FD6E671A94DC1E PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E

4 4

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

Microsoft DANE inbound and license requirement
by Sidsel Jensen 03 Jun '24

03 Jun '24

Hi fellow DANE enthusiasts, So last week Microsoft released some DANE documentation: https://learn.microsoft.com/en-us/purview/how-smtp-dane-works#how-can-excha… However it looks like Microsoft has put an E5 license requirement over the use of it once it's outside of Public Preview. Does anyone here know why they've come up with this requirement, which has a significant extra cost compared to an E3 or even an E1? It will for sure put a dampener on the adoption, which I find a bit nonsensical. Is there anybody on this list, with some MS insights that might shed some light on this decision? Kind Regards, Sidsel Jensen Architect of Deliverability and Abuse @ Open-Xchange

2 1