- dane-users - list.sys4.de

DANE-TA(2) private CAs and SHA-1
by Viktor Dukhovni 13 Jul '18

13 Jul '18

By using DANE-TA(2) TLSA records you can associate your SMTP server with a either a public or private (your own) issuer CA. This can simplify the management of TLSA records of multiple MX hosts by using a CNAME to a common location where you publish the shared CA key hash. Some care needs to be take to make sure that certificate chains issued by a private CA can be successfully validated by correctly configured DANE TLS clients. 1. Make sure the MX hostname of the end-entity server is one of the names in the subjectAltName extension of the server certificate. This is optional for DANE-EE(3), but is required for DANE-TA(2). Some MX hosts are known by different names when serving different domains. I don't recommend this, but can't stop you from doing it. In that case, all the names should appear in the certificate, or (if using server-side SNI) each name should appear in the corresponding certificate. 2. Make sure that the server certificate is replaced in a timely manner before it expires. This is also optional with DANE-EE(3), and required with DANE-TA(2). 3. [The motivation for this message]. Use broadly accepted cryptographic algorithms and parameters. For example, recent versions of GnuTLS by default no longer accept SHA-1 signatures in certificate chains. Some versions of Exim that support DANE are linked with GnuTLS, and the Exim maintainers are not presently inclined to re-enable SHA-1 support. Therefore, sites using private CAs with SHA-1 signatures may encounter problems receiving some email. (Public CA/B forum CAs no longer issue SHA-1 certificates.) For best interoperability use the SHA256 digest algorithm in certificate signatures. For best interoperability, use RSA key sizes of at least 1280 bits, and no more than 4096. The most common choice is 2048-bits. For ECDSA, stick with NIST P-256 (OpenSSL names for this ECDSA curve are prime256v1 and secp256r1). Today (after most of the small number of domains using SHA-1 with private CAs re-issued their certificates) the DANE survey finds only one MX host of one domain with SHA-1 private-CA signatures: semidefinite.de. IN MX 10 mail.semidefinite.de. so the impact of the GnuTLS policy is low. With a bit of luck, this post will help others avoid the same issue, and perhaps also the postmaster of the above domain will see it on one of the dane-users, postfix-users or exim-users lists, so the number of affected domains may soon be zero. -- Viktor.

1 0

Update on stats 2018-06
by Viktor Dukhovni 30 Jun '18

30 Jun '18

Credits: With additional data from Paul Vixie of Farsight Security, the DNSSEC coverage continues to improve. Summary: The DANE domain count is now 296,990. The number DNSSEC domains in the survey stands at 8,069,614. Thus DANE TLSA is deployed on 3.68% of domains with DNSSEC. As of today I count 296,990 domains with correct SMTP DANE TLSA records at every primary MX host that accepts connections[1]. As expected the bulk of the DANE domains are hosted by the DNS/email hosting providers who've enabled DANE support in bulk for the domains they host. It is starting to get crowded at the top of the list, so I'm now listing the top 15 MX host providers by domain count: 103783 transip.nl 96089 domeneshop.no 34141 active24.com 23491 udmedia.de 9646 bhosted.nl 2270 nederhost.nl 1940 provalue.nl (new this month) 1575 yourdomainprovider.net 1072 hi7.de 958 xcellerate.nl 874 surfmailfilter.nl 652 omc-mail.com 651 core-networks.de 588 interconnect.nl (new this month) 547 mailbox.org The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.cz/.de. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 10 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 4080 TOTAL 1394 DE, Germany 900 US, United States 509 NL, Netherlands 338 FR, France 163 GB, United Kingdom 121 CZ, Czech Republic 80 CA, Canada 59 SE, Sweden 58 CH, Switzerland 57 SG, Singapore IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6). 2043 TOTAL 768 DE, Germany 417 US, United States 282 NL, Netherlands 187 FR, France 89 GB, United Kingdom 68 CZ, Czech Republic 34 SE, Sweden 25 SG, Singapore 23 CH, Switzerland 14 SI, Slovenia There are 3402 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. The number of published MX host TLSA RRsets found is 4690. These cover 5012 distinct MX hosts (some MX hosts share the same TLSA records through CNAMEs). The number of domains that at some point were listed in Gmail's email transparency report is 157 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 87 are in recent reports: gmx.at fau.de deltion.nl travelbirdbelgique.be freenet.de hierinloggen.nl nic.br gmx.de interconnect.nl registro.br jpberlin.de ouderportaal.nl gmx.ch lrz.de overheid.nl open.ch mail.de pathe.nl anubisnetworks.com posteo.de politie.nl gmx.com ruhr-uni-bochum.de truetickets.nl mail.com tum.de uvt.nl societe.com uni-erlangen.de xs4all.nl solvinity.com unitybox.de domeneshop.no t-2.com unitymedia.de webcruitermail.no trashmail.com web.de aegee.org xfinity.com egmontpublishing.dk debian.org xfinityhomesecurity.com netic.dk freebsd.org xfinitymobile.com tilburguniversity.edu gentoo.org active24.cz octopuce.fr ietf.org clubcard.cz comcast.net isc.org cuni.cz dd24.net netbsd.org cvc.cz dns-oarc.net openssl.org itesco.cz gmx.net samba.org klubpevnehozdravi.cz hr-manager.net torproject.org knizni-magazin.cz inexio.net asf.com.pt nic.cz mpssec.net handelsbanken.se optimail.cz t-2.net iis.se smtp.cz xs4all.net minmyndighetspost.se bayern.de bhosted.nl skatteverket.se bund.de bit.nl t-2.si elster.de boozyshop.nl govtrack.us Of the ~297000 domains, 1142 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 266. Some of these have additional MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. A partial list is available at: https://github.com/danefail/list To avoid getting listed, please make sure to monitor the validity of your own TLSA records, and implement a reliable key rotation procedure. See: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 All the new blood in the survey has uncovered some previously unseen DNSSEC denial of existence breakage. After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 678. The top 20 name server operators with problem domains are: 127 mijnhostingpartner.nl 79 webspacecontrol.com / dotroll.com 56 dotserv.com 42 metaregistrar.nl 40 is.nl 32 tiscomhosting.nl 29 active24.cz (some broken wildcard cnames) 27 tse.jus.br 26 sylconia.net 14 host-redirect.com 13 psb1.org 13 nazwa.pl (some broken wildcard NS RRs) 12 zeptor.nl 12 nrdns.nl 11 blauwblaatje.nl 8 dnscluster.nl 7 forpsi.net 6 pcextreme.nl 6 glbns.com 6 domdom.hu If anyone has good contacts at one of these provides, please encourage them to remediate not only the broken domains (I can send them a list), but also the root cause that makes the breakage possible. The domains all whose nameservers have broken denial of existsnce that also appear in historical Google reports are: trt1.jus.br trtrj.jus.br tre-ce.jus.br tre-pe.jus.br tre-rj.jus.br tre-rs.jus.br tre-sc.jus.br tre-sp.jus.br tse.jus.br The last seven of these should be fixed shortly, the right parties have been informed, and I expect will have resolved promptly. -- Viktor. [1] Some domains deliberately include MX hosts that are always down, presumably as a hurdle to botnet SMTP code that gives up where real MTAs might persist. I am not a fan of this type of defence (it can also impose undue latency on legitimate email). However, provided the dead hosts still have TLSA records, (which don't need to match anything, just need to exist and be well-formed) there's no loss of security.

1 0

Update on stats 2018-05
by Viktor Dukhovni 31 May '18

31 May '18

Credits: Thanks to a substantial contribution of names of signed domains by Paul Vixie of Farsight Security, and smaller significant contribution by domains-index.com, the scope of the survey is substantially expanded from ~6.0 million to ~7.9 million domains. Unsurprisingly, the numbers for the major hosting providers are substantially larger than in April. Aside from the increase in the number of tested domains a new hosting provider "active24.com" (aka active24.cz) has enabled inbound and outbound DANE for their hosted domains. Thank you "active24.com" for improving the security of Internet email infrastructure. Summary: The DANE domain count is now 289,550. The number DNSSEC domains in the survey stands at 7,878,881, thus DANE TLSA is deployed on 3.67% of domains with DNSSEC. As of today I count 289,550 domains with correct SMTP DANE TLSA records at every primary MX host that accepts connections[1]. As expected the bulk of the DANE domains are hosted by the DNS/email hosting providers who've enabled DANE support in bulk for the domains they host. It is starting to get crowded at the top of the list, so I'm now listing the top 15 MX host providers by domain count: 100271 transip.nl 95922 domeneshop.no 33299 active24.com 23389 udmedia.de 9655 bhosted.nl 2281 nederhost.nl 1547 yourdomainprovider.net 1032 hi7.de 955 xcellerate.nl 927 surfmailfilter.nl 634 core-networks.de 629 omc-mail.com 508 mailbox.org 495 secure-gw.de 433 systemec.nl The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.cz/.de. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 10 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 1402 DE, Germany 870 US, United States 508 NL, Netherlands 344 FR, France 166 GB, United Kingdom 121 CZ, Czech Republic 81 CA, Canada 65 SE, Sweden 59 CH, Switzerland 51 SG, Singapore IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6). 754 DE, Germany 431 US, United States 280 NL, Netherlands 187 FR, France 88 GB, United Kingdom 67 CZ, Czech Republic 36 SE, Sweden 24 SG, Singapore 23 CH, Switzerland 14 SI, Slovenia There are 3331 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. The number of published MX host TLSA RRsets found is 4785. These cover 5103 distinct MX hosts (some MX hosts share the same TLSA records through CNAMEs). The number of domains that at some point were listed in Gmail's email transparency report is 152 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 82 are in recent reports: gmx.at gmx.de overheid.nl travelbirdbelgique.be jpberlin.de pathe.nl nic.br lrz.de politie.nl registro.br mail.de truetickets.nl gmx.ch posteo.de uvt.nl open.ch ruhr-uni-bochum.de xs4all.nl anubisnetworks.com tum.de domeneshop.no gmx.com uni-erlangen.de handelsbanken.no mail.com unitybox.de webcruitermail.no solvinity.com unitymedia.de aegee.org trashmail.com web.de debian.org xfinity.com egmontpublishing.dk freebsd.org xfinityhomesecurity.com netic.dk gentoo.org xfinitymobile.com tilburguniversity.edu ietf.org active24.cz insee.fr isc.org clubcard.cz octopuce.fr netbsd.org cuni.cz comcast.net openssl.org cvc.cz dd24.net samba.org itesco.cz dns-oarc.net torproject.org klubpevnehozdravi.cz gmx.net asf.com.pt localssrcapp.cz hr-manager.net handelsbanken.se nic.cz mpssec.net iis.se smtp.cz t-2.net minmyndighetspost.se bayern.de xs4all.net skatteverket.se bund.de bhosted.nl t-2.si elster.de bit.nl govtrack.us fau.de boozyshop.nl freenet.de ouderportaal.nl Of the ~289000 domains, 1466 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 220. Some of these have additional MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. A partial list is available at: https://github.com/danefail/list To avoid getting listed, please make sure to monitor the validity of your own TLSA records, and implement a reliable key rotation procedure. See: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 All the new blood in the survey has uncovered some previously unseen DNSSEC denial of existence breakage. After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 1171. The top 20 name server operators with problem domains are: 793 webspacecontrol.com / dotroll.com 52 mijnhostingpartner.nl 49 dotserv.com 22 sylconia.net 16 firstfind.nl 13 psb1.org 11 nazwa.pl 11 blauwblaatje.nl 10 metaregistrar.nl 8 zeptor.nl 8 tse.jus.br 8 dnscluster.nl 8 active24.cz 7 ignum.com 6 vultr.com 6 tiscomhosting.nl 6 host-redirect.com 6 glbns.com 6 domdom.hu 6 1cocomo.com The domains all whose nameservers have broken denial of existsnce that also appear in historical Google reports are: tre-ce.jus.br tre-sc.jus.br tre-rj.jus.br tre-sp.jus.br tse.jus.br -- Viktor. [1] Some domains deliberately include MX hosts that are always down, presumably as a hurdle to botnet SMTP code that gives up where real MTAs might persist. I am not a fan of this type of defence (it can also impose undue latency on legitimate email). However, provided the dead hosts still have TLSA records, (which don't need to match anything, just need to exist and be well-formed) there's no loss of security.

1 0

tlsa binary fails with certificate error
by Hoggins! 22 May '18

22 May '18

Hello list, Not sure this is the right place to post, maybe I'd better mail the maintainer of the package, but you might have encountered the same issue. I've always published TLSA records for my domains/subdomains, and using an automated (Cron) job to do this, invoking the tlsa script (provided by the hash-slinger package on my Fedora machines). Now for about a few weeks now, the tlsa script fails, complaining with the following error message: Could not verify local certificate: no start line. Traceback (most recent call last): File "/usr/bin/tlsa", line 889, in <module> genRecords(args.host, args.protocol, args.port, chain, args.output, args.usage, args.selector, args.mtype) NameError: name 'chain' is not defined I'm using LetsEncrypt for my certificates, and I can't see what changed recently. I'm running the tlsa script against a concatenated (intermediate + domain certificate) PEM file, and it has always worked just fine. During my investigations, I found that an "openssl verify" will fail on the file, saying "unable to get local issuer certificate". I have no way to tell if this has always failed, or if this is new behavior. I'd be glad to hear if you have any thoughts about my issue. Thanks! Hoggins!

2 6

Update on stats 2018-04
by Viktor Dukhovni 02 May '18

02 May '18

Summary: The DANE domain count is now 205,351. Much of the increase is the result of better (though still incomplete) coverage of the ".no" TLD, but some is due to the more gradual steady increase in the breadth of adoption. I hope to broaden the coverage further in May. The number DNSSEC domains in the survey stands at 6,017,669, thus DANE TLSA is deployed on 3.41% of domains with DNSSEC. Data graciously provided by Gmail shows that 16,170 of the DANE domains have received recent email from at least 5 senders. And 2449 (vs. 1,542 a year ago out of a then total 137,244 domains) of the domains have received at least 50 recent messages. As of today I count 205,351 domains with correct SMTP DANE TLSA records at every primary MX host that accepts connections[1]. As expected the bulk of the DANE domains are hosted by 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: 90580 domeneshop.no (result of better .no coverage) 67122 transip.nl 19107 udmedia.de 6142 bhosted.nl 1787 nederhost.nl 1214 yourdomainprovider.net 878 hi7.de (name change from ec-elements.com) 751 surfmailfilter.nl 549 core-networks.de 456 omc-mail.com The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.de. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 10 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 1374 DE, Germany 922 US, United States 490 NL, Netherlands 358 FR, France 157 GB, United Kingdom 125 CZ, Czech Republic 88 CA, Canada 65 SE, Sweden 56 CH, Switzerland 49 SG, Singapore IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6). 782 DE, Germany 474 US, United States 286 NL, Netherlands 221 FR, France 94 GB, United Kingdom 76 CZ, Czech Republic 37 SE, Sweden 26 SG, Singapore 24 CH, Switzerland 16 IE, Ireland There are 3264 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. The number of published MX host TLSA RRsets found is 4675. These cover 4933 distinct MX hosts (some MX hosts share the same TLSA records through CNAMEs). The number of domains that at some point were listed in Gmail's email transparency report is 132 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 71 are in recent reports: gmx.at ruhr-uni-bochum.de politie.nl travelbirdbelgique.be tum.de uvt.nl nic.br uni-erlangen.de xs4all.nl registro.br unitybox.de domeneshop.no gmx.ch unitymedia.de handelsbanken.no open.ch web.de webcruitermail.no anubisnetworks.com dk-hostmaster.dk aegee.org gmx.com egmontpublishing.dk debian.org mail.com tilburguniversity.edu freebsd.org solvinity.com insee.fr gentoo.org trashmail.com octopuce.fr ietf.org xfinity.com comcast.net isc.org xfinityhomesecurity.com dd24.net netbsd.org xfinitymobile.com dns-oarc.net openssl.org bayern.de gmx.net samba.org bund.de hr-manager.net torproject.org elster.de mpssec.net asf.com.pt fau.de t-2.net handelsbanken.se freenet.de xs4all.net minmyndighetspost.se gmx.de bhosted.nl skatteverket.se jpberlin.de boozyshop.nl t-2.si lrz.de ouderportaal.nl mail.co.uk mail.de overheid.nl govtrack.us posteo.de pathe.nl Of the ~205000 domains, 1502 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 258. Some of these also have MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. Goging forward I'm no longer listing the problem MX hosts here. Instead, I am contributing data to the github project that tracks domains with DANE failures: https://github.com/danefail/list Please open issues or pull requests if you domains that are not listed. To avoid getting listed, please make sure to monitor the validity of your own TLSA records, and implement a reliable key rotation procedure. See: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 110. The top 10 name server operators with problem domains are: 8 tse.jus.br 8 psb1.org 8 nazwa.pl 7 active24.cz 5 tiscomhosting.nl 4 ignum.com 4 glbns.com 4 centralpark.se 4 army.mil 4 1cocomo.com No domains all whose nameservers have broken denial of existsnce appear in historical Google reports. -- Viktor. [1] Some domains deliberately include MX hosts that are always down, presumably as a hurdle to botnet SMTP code that gives up where real MTAs might persist. I am not a fan of this type of defence (it can also impose undue latency on legitimate email). However, provided the dead hosts still have TLSA records, (which don't need to match anything, just need to exist and be well-formed) there's no loss of security.

1 0

The danefail list on Github
by Viktor Dukhovni 14 Apr '18

14 Apr '18

Now that I am able to contribute commits to the danefail list at: https://github.com/danefail/list https://raw.githubusercontent.com/danefail/list/master/dane_fail_list.dat I've pushed data for many of the domains served by MX hosts with persistent issues. You can use this list to confirm that you're not the only one with delivery issues to one of the listed domains, and perhaps create exceptions for such domains in your configuration. Also, please try to not end up on the list: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 Do implement monitoring of your own TLSA records and DNSSEC zone. Do implement a key/cert rollover process that ensures that matching TLSA records are in place for both the old and the new cert have been in place for some time (multiple TTLs and slave zone refresh times) before deploying new certificate chains. When using DANE-TA(2) TLSA records, make sure that the certificate does not expire, has a name that matches the MX hostname and the trust-anchor certificate is included in the server's chain file. -- Viktor.

1 0

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
by Viktor Dukhovni 10 Apr '18

10 Apr '18

Please read the TLS WG consensus call thread on the DNSSEC chain extension, and comment for either publish as-is or the changes I and others are advocating (which IMHO are needed for plausible utility in the web space). Thread: https://www.ietf.org/mail-archive/web/tls/current/threads.html#25929 Rationale for change: https://www.ietf.org/mail-archive/web/tls/current/msg25936.html Why proposed pinning TTL is analogous to STS and not HPKP: https://www.ietf.org/mail-archive/web/tls/current/msg25956.html -- Viktor.

1 0

Re: [dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension (fwd)
by Viktor Dukhovni 05 Apr '18

05 Apr '18

> On Apr 5, 2018, at 2:43 AM, John Gilmore <gnu(a)toad.com> wrote: > > Looks from this distance like the usual obstruction, i.e. "just give > us a few more years of CA revenues, by delaying this standard further > by demanding to add stuff that could easily have been added by a > followup RFC". I am confused, the folks most closely tied to the current browser/CA revenue model are proposing moving ahead with the crippled standard as-is, and those of us who want a standard that would be usable in browsers are asking for some changes, that should not cause much delay, but are needed to make the spec viable for browser HTTPS. So you comment about a follow-up RFC and delay is perplexing. I certainly do not wish delay adoption in HTTPS I'm advocating for it, but that requires a small delay in publication to add two key missing features. * Lack of denial of existence * Lack of an extended TTL that commits the server to support the extension for the specified time (and provide either TLSA records or denial of existence of same or even DS records for the domain or some parent). Without these, the protocol suffers trivial "stripping" downgrades. A server that implements DANE and supports the extension should be able to expect that clients will not ignore its absence and continue with legacy WebPKI. For if that's the case, the extension is pointless for the vast majority of applications (including browsers) where its adoption would need to be incremental. See the TLS WG discussion for details. -- Viktor.

1 0

TLS dane-chain extension: viability in browsers and the like...
by Viktor Dukhovni 05 Apr '18

05 Apr '18

If you want to (some day) see DANE support in browsers and other existing applications where adoption would be necessarily incremental, please read and consider responding on the IETF TLS WG list to: https://www.ietf.org/mail-archive/web/tls/current/msg25937.html the parent thread is: https://www.ietf.org/mail-archive/web/tls/current/threads.html#25929 where you mind other posts that flesh out the pros/cons. And of course please take a look at the draft to make your own first-hand conclusions: https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07 -- Viktor. P.S. I posted a shorter version of this on Twitter: https://twitter.com/VDukhovni/status/981682242174046210

1 0

Update on stats 2018-03
by Viktor Dukhovni 01 Apr '18

01 Apr '18

Summary: The total domain count is now 185948. Approximately 6500 of the ~10000 new domains result from processing a new source for some additional .no and .nl domain nanes. The number DNSSEC domains in the survey stands at 5382667, thus DANE TLSA is deployed on 3.45% of domains with DNSSEC. Many DNSSEC domains use third-party MX hosts, that don't have DNSSEC, so they can't benefit from DANE until their providers secure the MX hosts. Please ask your provider to enable DNSSEC and DANE on their MX hosts. [ It would be especially significant if "redirect.ovh.net" were to implement DNSSEC+DANE. If someone personally knows the right people to gently nudge at ovh.net, please do. ] As of today I count 185948 domains with correct SMTP DANE TLSA records at every primary MX host that accepts connections[1]. As expected the bulk of the DANE domains are hosted by 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: 73807 domeneshop.no 65101 transip.nl 19168 udmedia.de 6177 bhosted.nl 1807 nederhost.nl 1228 yourdomainprovider.net 867 ec-elements.com 748 surfmailfilter.nl 542 core-networks.de 438 omc-mail.de The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.de. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 10 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented): 1289 DE, Germany 830 US, United States 457 NL, Netherlands 338 FR, France 164 GB, United Kingdom 109 CZ, Czech Republic 80 CA, Canada 59 SE, Sweden 58 CH, Switzerland 50 BR, Brazil IPv6 is still comparatively rare for MX hosts, and the top 10 countries by DANE MX host IPv6 GeoIP are (same top 6). 710 DE, Germany 407 US, United States 255 NL, Netherlands 195 FR, France 102 GB, United Kingdom 58 CZ, Czech Republic 33 SE, Sweden 25 CH, Switzerland 23 SG, Singapore 14 SI, Slovenia There are 3372 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. The number of published MX host TLSA RRsets found is 4544. These cover 4834 distinct MX hosts (some MX hosts share the same TLSA records through CNAMEs). [ Previous reports inadvertently included some "orphan" MX hosts in the database, that are no longer tied to any domains, these are no longer reported, so the numbers are somewhat smaller this month. Without the correction, the numbers would have been 5485 and 5795. ] The number of domains that at some point were listed in Gmail's email transparency report is 131 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 72 are in recent reports: gmx.at posteo.de pathe.nl travelbirdbelgique.be ruhr-uni-bochum.de politie.nl nic.br tum.de uvt.nl registro.br uni-erlangen.de xs4all.nl gmx.ch unitybox.de domeneshop.no open.ch unitymedia.de handelsbanken.no anubisnetworks.com web.de webcruitermail.no gmx.com dk-hostmaster.dk aegee.org isavedialogue.com egmontpublishing.dk debian.org mail.com tilburguniversity.edu freebsd.org solvinity.com insee.fr gentoo.org trashmail.com octopuce.fr ietf.org xfinity.com comcast.net isc.org xfinityhomesecurity.com dd24.net netbsd.org xfinitymobile.com dns-oarc.net openssl.org bayern.de gmx.net samba.org bund.de hr-manager.net torproject.org elster.de mpssec.net asf.com.pt fau.de t-2.net handelsbanken.se freenet.de xs4all.net minmyndighetspost.se gmx.de bhosted.nl skatteverket.se jpberlin.de boozyshop.nl t-2.si lrz.de ouderportaal.nl mail.co.uk mail.de overheid.nl govtrack.us Of the ~186000 domains, 1500 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 202. Some of these also have MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. Below is the list of underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: 88oddil.cz mail.itconnect.ro mx1.em54.net andbraiz.com mail.itsmine.com mx1.em56.net andersonvasconcelos.com.br mail.labbrack.se mx1.email.youwerehere.info anubis.delphij.net mail.lavabit.no mx2.aquasoft.cz bounder.steelyard.nl mail.lsd.is mx2.em54.net coolmx.net-art.cz mail.mxdove.com mx2.em56.net demo.liveconfig.com mail.myzt.nl mx2.email.youwerehere.info diablo.sgt.com mail.netistan.ch mx2.mindrun.de din.mta.din.cz mail.nonoserver.info mx2.pfp.de eufront.stansoft.bg mail.olgui.net petg.cz eumembers.stansoft.bg mail.pasion.ro pinus.dafcorp.net gaia.nfx.cz mail.rapidfuse.io plesk2.acknowledge.nl gamepixel.eu mail.rostit.se pop.co.za goldcars.mta.din.cz mail.scrz44.de rootbox.me gsmapp.com.br mail.seslost.cz sat-an--net.mta.din.cz homer.jpbe.de mail.victorycity.com.hk servmail.fr intranet.nctechcenter.com mail.voorschoten.nl smtp-1.httrack.com itaskmanager.ovh mail.wassenaar.nl smtp.bl.lybre.net kou--li.mta.din.cz mail.werkorganisatieduivenvoorde.nl smtp.klam.com ma.qbitnet.com mail.wodv.nl smtp.sauron-mordor.net mail.3c7.de mail.zionbit.cz smtp1.lococensus.nl mail.abanto-zierbena.org mail.zx.com smtp2.lococensus.nl mail.all4.de mail2.subse.eu solventtruck.mta.din.cz mail.allq.cz mail2.victorycity.com.hk stmics01.smia-automotive.com mail.bacrau.ro mailb.kamadu.eu stmics02.smia-automotive.com mail.castleturing.net maxhunter.com.br tusk.sgt.com mail.davidbodnar.cz milhouse.jpbe.de vm-1.eveng.de mail.digitalwebpros.com mminetto.com.br vps.du.ie mail.diplomatic.email mx.bels.cz wantuz.shannara.ru mail.dnsmadefree.com mx.datenknoten.me webmail.headsite.se mail.efflam.net mx.itconnect.ro webmail.kassoft.eu mail.familie-sander.rocks mx.mail.klinknetz.de webmail.vivisol.nl mail.fscker.nl mx.promail.saarland wizard.itsmine.com mail.i-bible.com mx01.qusign.net www.mtg.de Please make sure to monitor the validity of your TLSA records, and implement a reliable key rotation procedure. See: https://dane.sys4.de/common_mistakes http://imrryr.org/~viktor/ICANN61-viktor.pdf http://imrryr.org/~viktor/icann61-viktor.mp3 http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 After eliminating parked domains that do not accept email of any kind, the number of "real" email domains with bad DNSSEC support stands at 104. The top 10 name server operators with problem domains are: 8 psb1.org 7 tse.jus.br 7 active24.cz 6 tiscomhosting.nl 5 nazwa.pl 5 metaregistrar.nl 4 ignum.com 4 glbns.com 4 army.mil 4 1cocomo.com Only one domain all whose nameservers have broken denial of existsnce appears in historical Google reports: http://dnsviz.net/d/_25._tcp.mx1.harsh.monkeybrains.net/WsEoNQ/dnssec/ http://dnsviz.net/d/_25._tcp.mx2.harsh.monkeybrains.net/WsEiKA/dnssec/ the monkeybrains.net SOA record is likely modified *after* the zone is signed, making negative replies "bogus". -- Viktor. [1] Some domains deliberately include MX hosts that are always down, presumably as a hurdle to botnet SMTP code that gives up where real MTAs might persist. I am not a fan of this type of defence (it can also impose undue latency on legitimate email). However, provided the dead hosts still have TLSA records, (which don't need to match anything, just need to exist and be well-formed) there's no loss of security.

1 0