February 2017 - dane-users

Don't forget to add TLSA records for black-hole MX hosts
by Viktor Dukhovni 03 Mar '17

03 Mar '17

Some domains with DANE-TLSA records for their primary MX hosts neglect to publish DANE TLSA for secondary and/or "black-hole" (spam magnet) MX hosts. Consider nic.cz, until recently their "bh.nic.cz" host had no TLSA records (and SMTP connections to that host would time out). This gives an active on-path MiTM attacker opportunity to block connections to the working MX hosts, and accept unauthenticated connections to the black-hole MX host. After they were notified of the problem, they made changes, and now we see TLSA records associated with all the MX hosts, including "bh.nic.cz": nic.cz. IN MX 10 mail.nic.cz. ; NOERROR AD=1 nic.cz. IN MX 20 mx.nic.cz. ; NOERROR AD=1 nic.cz. IN MX 30 bh.nic.cz. ; NOERROR AD=1 ; mail.nic.cz. IN A 217.31.204.67 ; NOERROR AD=1 mail.nic.cz. IN AAAA 2001:1488:800:400::400 ; NOERROR AD=1 _25._tcp.mail.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1 ; mx.nic.cz. IN A 217.31.58.56 ; NOERROR AD=1 mx.nic.cz. IN AAAA 2001:1ab0:7e1e:c574:7a2b:cbff:fe33:7019 ; NOERROR AD=1 _25._tcp.mx.nic.cz. IN TLSA 3 1 1 aa7b93daab084536530bd3256e9ceff4557cb43512640f7ab64487dc9ca14fab ; NOERROR AD=1 ; bh.nic.cz. IN A 217.31.204.252 ; NOERROR AD=1 bh.nic.cz. IN AAAA ? ; NODATA AD=1 _25._tcp.bh.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1 I've not yet nagged "iis.se" or "wia.cz", and there we see that only one of the two MX hosts has a TLSA record: iis.se. IN MX 5 mx1.iis.se. ; NOERROR AD=1 iis.se. IN MX 5 mx2.iis.se. ; NOERROR AD=1 ; mx1.iis.se. IN A 91.226.36.35 ; NOERROR AD=1 mx1.iis.se. IN AAAA 2a00:801:f0:106::35 ; NOERROR AD=1 _25._tcp.mx1.iis.se. IN TLSA 3 1 1 0894a6827f435ccb7435552290ff13e704776e4568235bbc899f515de3314ce3 ; NOERROR AD=1 ; mx2.iis.se. IN A 91.226.37.39 ; NOERROR AD=1 mx2.iis.se. IN AAAA 2001:67c:124c:2007::39 ; NOERROR AD=1 _25._tcp.mx2.iis.se. IN TLSA ? ; NXDOMAIN AD=1 wia.cz. IN MX 10 antispam.wia.cz. ; NOERROR AD=1 wia.cz. IN MX 20 bntispam.wia.cz. ; NOERROR AD=1 ; antispam.wia.cz. IN A 80.250.3.18 ; NOERROR AD=1 antispam.wia.cz. IN AAAA ? ; NODATA AD=1 _25._tcp.antispam.wia.cz. IN TLSA 3 1 1 3b67e777e8a11d373fae958c3ea5a200bd791813c0e6e9be34e2965bcfcc071e ; NOERROR AD=1 ; bntispam.wia.cz. IN A 31.7.247.78 ; NOERROR AD=1 bntispam.wia.cz. IN AAAA ? ; NODATA AD=1 _25._tcp.bntispam.wia.cz. IN TLSA ? ; NXDOMAIN AD=1 While during initial deployment it is natural to proceed incrementally and add TLSA records to one MX host at a time, and test thoroughly before moving on to the rest, the end-state should be to publish TLSA records for all MX hosts, not a proper subset. -- Viktor.

3 2

Update on stats
by Viktor Dukhovni 27 Feb '17

27 Feb '17

As of today I count 110505 domains with correct DANE TLSA records for SMTP. As expected the bulk of the DANE domains are hosted the handful of DNS/hosting providers who've enabled DANE support in bulk for the domains they host. The top 10 MX host providers by domain count are: 43813 domeneshop.no 35704 transip.nl 15495 udmedia.de 2022 bhosted.nl 1332 nederhost.net 896 ec-elements.com 409 core-networks.de 307 uvt.nl 282 bit.nl 275 omc-mail.com The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, and in particular .de and .nl. There are 2401 unique zones in which the underlying MX hosts are found, this counts each of the above providers as just one zone, so is a measure of the breadth of adoption in terms of servers deployed. Alternatively, a similar number is seen in the count (2522) of distinct MX host server certificates that support the same ~110000 domains. Of the ~110000 domains, 565 have "partial" TLSA records, that cover only a subset of the MX hosts. While this protects traffic to some of the MX hosts, such domains are still vulnerable to the usual active attacks via the remaining MX hosts. The number of domains with incorrect TLSA records or failure to advertise STARTTLS (even though TLSA records are published) stands today at 64 (~4 are recent additions that will likely be resolved soon, the remaining ~60 are the for now stable population of broken domains). This month I'm posting the top 50 entries, these are domains that have been on that list for the longest time. Hall of Shame: castleturing.net goldenhairdafo.net dexalo.de nonoserver.info inu.nl dexalo.eu wm.net.nz dnsmadefree.com digitalwebpros.com apachedemo.de z0z0.me jeremyness.com oostergo.net pksvice.cz maximilian-greger.com thothnet.org ttygap.net copi.org wipedivision.cz bels.cz delphij.net rajmax.si baobrien.org poderdoalimento.com.br acsemb.org baobrien.guru rnrfunco.net dhautefeuille.eu pieterpottie.com sgt.com dinepont.fr sylvieandpieter.com rnrfunco.com hlfh.space sylviesfollies.com puz.de 12xu.info flatcap.org zencrypt.de warunek.net russon.org freeservices.net giesen.me amadigi.ovh kuzenkov.net kamikazekippetjes.nl duffau.net obninsk.biz myzt.nl daallexx.eu The number of domains with bad DNSSEC support is 434. The top 10 DNS providers (by broken domain count) are: 62 axc.nl - Slated to be resolved 37 infracom.nl - Slated to be resolved 18 loopia.se 18 active24.cz 16 domaincontrol.com - notified 14 jsr-it.nl 12 rdw.nl 12 cas-com.net 11 dootall.com - notified 10 ignum.com Around 100 of the broken domains have at least one working nameserver, and so are email-reachable, given enough retries. The number of domains that at some point were listed in Gmail's transparency report is 99 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these 44 are in recent reports (February 2017): Hall of Fame: gmx.at mail.de asp4all.nl nic.br posteo.de ouderportaal.nl registro.br ruhr-uni-bochum.de overheid.nl gmx.ch tum.de xs4all.nl open.ch uni-erlangen.de domeneshop.no gmx.com unitymedia.de webcruitermail.no mail.com web.de debian.org trashmail.com enron.email freebsd.org xfinity.com octopuce.fr gentoo.org bayern.de comcast.net ietf.org bund.de dd24.net isc.org fau.de gmx.net netbsd.org gmx.de hr-manager.net samba.org jpberlin.de t-2.net torproject.org lrz.de xs4all.net A recent addition that is not listed above is "exim.org". It seems that "exim.org" mailing lists don't process enough email to land on Google transparency reports. Similarly, "openssl.org" used to be on this list, and still has working TLSA records, but it seems no longer generates enough email traffic to be on Google's reports. I don't have any way to measure how many domains enable DANE outbound but aren't using DNSSEC for their own domain or are not publishing TLSA records. It is easy to do, just fire up a local validating resolver, adjust /etc/resolv.conf to list only 127.0.0.1 and/or ::1, and add a couple of lines to main.cf. So the stats I am reporting reflects only DANE adoption for inbound email. -- Viktor.

1 0

smtpdane testing tool (early alpha)
by Phil Pennock 25 Feb '17

25 Feb '17

Folks, If you have Golang 1.8 (or newer) installed, my "smtpdane" tool might be of interest. mkdir ~/go go get go.pennock.tech/smtpdane There's a README.md with invoking hints, etc. Current git hosting has this visible at: https://github.com/PennockTech/smtpdane I'll repeat the warning at the top of the README.md: } EARLY ALPHA SOFTWARE } } THIS HAS NOT YET BEEN TESTED TO CONFIRM IT FAILS WHEN IT SHOULD, } AGAINST BAD CERTIFICATES OR DNS So yes, I need to create a test suite still, instead of relying upon ad-hoc testing against various servers. That said, while I wouldn't yet rely upon the tool for monitoring or assurance, it's useful for taking a look. Also: Go 1.8 is a very recent release; please do check version. This is not a frivolous requirement on my part: Go 1.8 introduced the hooks into the TLS certificate verification logic which I need to splice DANE logic in there. The code should "cleanly" fail to build with an obvious error message if an older toolchain is used. At present, smtpdane still relies upon a validating DNS resolver, instead of validating DNSSEC itself. For use as a monitoring component, I'd like to remove that dependency. smtpdane -help smtpdane -mx spodhuis.org Every MX host, every IP, connected to in parallel and success reported. Feedback welcome. There's a TODO of things I know still need to be done. Thanks, -Phil

1 0

TLSA record TTL values
by John Allen 22 Feb '17

22 Feb '17

Is the any recommendation as to the TTL for TLSA records? I would imagine fairly short as if the is a problem you want the old ones gone ASAP! John A

2 1

Letsencrypt & TLSA - automation
by John Allen 21 Feb '17

21 Feb '17

Attached is a bash script that I am developing to automate the generation of TLSA records from Letsencrypt certificates. the script is called from the certbot renew hook, it can also be run stand alone - Certbot_TLSAgen path-to-certificate "space separated list of domains included in cert" It seems to work, but would some kind sole take a look and where I have or are about to screw up. Any suggestions as to how to get the output into my DNS (Bind9) preferably without using nsupdate. I am not keen on nsupdate as it makes a mess of the zone files, which I use as documentation for my DNS. Has anybody heard of a electronic "one time pad" system. TIA JohnA

5 8

Re: Letsencrypt & TLSA - automation
by John Allen 20 Feb '17

20 Feb '17

Is the process to update the serial number automatic? If so care to share. On 2017-02-20 4:04 AM, Casper Gielen wrote: > Op 19-02-17 om 19:20 schreef John Allen: >> Attached is a bash script that I am developing to automate the >> generation of TLSA records from Letsencrypt certificates. >> >> the script is called from the certbot renew hook, it can also be run >> stand alone - Certbot_TLSAgen path-to-certificate "space separated list >> of domains included in cert" >> >> It seems to work, but would some kind sole take a look and where I have >> or are about to screw up. >> >> >> Any suggestions as to how to get the output into my DNS (Bind9) >> preferably without using nsupdate. I am not keen on nsupdate as it makes >> a mess of the zone files, which I use as documentation for my DNS. > It may not be the cleanest method, but I use the INCLUDE statement in my > zones to include snippets of externally maintained information. > > The script I use outputs the required records and I just put it in the > right file and trigger a procedure to update the serial number and > reload Bind. >

2 1