From ietf-dane at dukhovni.org Mon Apr 1 07:30:33 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Apr 2019 01:30:33 -0400 Subject: Update on stats 2019-03 Message-ID: <20190401053033.GA1352@straasha.imrryr.org> Summary: The DANE domain count is now 1,107,851 The number of domains that return DNSSEC-validated replies in response to MX queries is 9,525,120. Thus DANE TLSA is deployed on 11.63% of domains with DNSSEC. Credits: The coverage of DNSSEC domains continues to improve with ongoing data support from Paul Vixie of Farsight Security. Credits also due to ICANN for gTLD data via CZDS, and to the TLD registries for .CH, .COM, .DK, .FR, .INFO, .IS, .LI, .NL, .NU, .ORG and .SE. More data sources of ccTLD signed delegations welcome. As of today I count 1,107,851 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 for the customer domains they host. The top 20 MX host providers by domain count are: 682345 one.com 122842 transip.nl 97106 domeneshop.no 35828 active24.com 32803 vevida.com 24093 udmedia.de 16091 flexfilter.nl 12932 onebit.cz 11039 bhosted.nl 5992 netzone.ch 5657 previder.nl 3901 ips.nl 3535 interconnect.nl 2490 provalue.nl 2343 nederhost.nl 1646 nmugroup.com 1445 yourdomainprovider.net 1328 hi7.de 1308 xcellerate.nl 1307 prolocation.net The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.cz/.de/.eu/.be. Speaking of countries, the IPv4 GeoIP distribution of DANE-enabled MX hosts shows the below top 20 countries (each unique IP address is counted, so multi-homed MX hosts are perhaps somewhat over-represented). 4977 TOTAL 1680 DE, Germany 1026 US, United States 674 NL, Netherlands 382 FR, France 204 GB, United Kingdom 170 CZ, Czechia 104 CA, Canada 80 SG, Singapore 71 CH, Switzerland 69 SE, Sweden 48 DK, Denmark 45 IE, Ireland 40 AU, Australia 39 AT, Austria 38 BR, Brazil 33 FI, Finland 29 PL, Poland 25 RU, Russia 21 JP, Japan 18 IT, Italy IPv6 is still comparatively rare for MX hosts, and the top 20 countries by DANE MX host IPv6 GeoIP are: 1834 TOTAL 677 DE, Germany 309 NL, Netherlands 221 FR, France 170 US, United States 111 CZ, Czechia 51 GB, United Kingdom 40 SE, Sweden 27 RU, Russia 27 CH, Switzerland 26 CA, Canada 20 AT, Austria 13 DK, Denmark 12 IE, Ireland 12 AU, Australia 11 NO, Norway 10 FI, Finland 10 BR, Brazil 9 SI, Slovenia 7 UA, Ukraine 7 PL, Poland There are 4176 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 6156. These cover 6594 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 229 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 114 are in recent (last 90 days of) reports: univie.ac.at ruhr-uni-bochum.de minbzk.nl gmx.at tu-darmstadt.de mycom.nl nic.br tum.de ouderportaal.nl registro.br uni-erlangen.de overheid.nl gmx.ch unitybox.de pathe.nl open.ch unitymedia.de photofacts.nl anubisnetworks.com web.de photofactsacademy.nl fmc-na.com dk-hostmaster.dk politie.nl gmx.com egmontpublishing.dk previder.nl habr.com netic.dk rijksoverheid.nl hotelsinduitsland.com tilburguniversity.edu ssonet.nl kpn.com dovecot.fi transip.nl mail.com ac-strasbourg.fr truetickets.nl one.com insee.fr utwente.nl solvinity.com octopuce.fr uvt.nl t-2.com web200.hu xs4all.nl telfort.com comcast.net domeneshop.no trashmail.com gmx.net handelsbanken.no xfinity.com habramail.net webcruitermail.no xfinityhomesecurity.com hr-manager.net atelkamera.nu xfinitymobile.com inexio.net aegee.org active24.cz mpssec.net debian.org cuni.cz procurios.net freebsd.org itesco.cz riseup.net gentoo.org klubpevnehozdravi.cz t-2.net ietf.org onebit.cz transip.net isc.org smtp.cz vevida.net netbsd.org virusfree.cz xs4all.net openssl.org bayern.de atletiekunie.nl ozlabs.org bund.de bhosted.nl samba.org elster.de bluerail.nl torproject.org fau.de boozyshop.nl asf.com.pt freenet.de corpoflow.nl handelsbanken.se gmx.de hierinloggen.nl iis.se jpberlin.de interconnect.nl minmyndighetspost.se lrz.de intermax.nl personligalmanacka.se mail.de mailplus.nl skatteverket.se posteo.de markteffectmail.nl govtrack.us Of the DANE email domains, 2044 are listed in the Alexa top 1 million (web site) list. Of the ~1.11 million domains, 2403 have "partial" TLSA records, that cover only a subset of the (secondary) 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 376. 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 https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources 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, the number of "real" email domains with bad DNSSEC support stands at 1160. The top 10 name server operators with problem domains are: 544 mijnhostingpartner.nl 95 epik.com 42 metaregistrar.nl 35 dotserv.com 35 binero.se 34 tiscomhosting.nl 31 nrdns.nl 29 sylconia.net 26 active24.cz 20 movenext.nl [ Some of these also have denial of existence problems at many more domains that don't receive mail, so the problem is not operationally significant in those cases, but could become larger, if more email-enabled signed domains start using these servers. For the top two, these additional domains number well over one thousand each. ] If anyone has good contacts at some of these providers, 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. Seven of the domains all whose nameservers have broken denial of existence appear in historical Google reports: trt01.gov.br trtrio.gov.br trt1.jus.br trtrj.jus.br accenturealumni.com rackeo.host sauditelecom.com.sa -- 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. From ietf-dane at dukhovni.org Wed Apr 17 10:08:21 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 17 Apr 2019 04:08:21 -0400 Subject: Upcoming Let's Encrypt intermediate issuer certificate change... Message-ID: <7BAE66FA-C80F-4003-AFE3-8E1F64762FE9@dukhovni.org> If you're relying on DANE TLSA "2 0 1" or "2 0 2" records that the match the current Let's Encrypt Intermediate certificate, you need to make appropriate plans for the switchover to a new intermediate CA cert on 2010-07-08: https://scotthelme.co.uk/lets-encrypt-to-transition-to-isrg-root/ this will result in a change in the content (and digest) of the intermediate issuer cert. But the underlying public key is *not* changing. Therefore, the sensible solution is before then to switch to "2 1 1" records that will continue to work across the cutover. The "2 1 1" record will of course have a different digest from the "2 0 1" record (and likewise for "2 1 2" vs. "2 0 2"). The stable key digests are: 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 2 1 2 774fad8c9a6afc2bdb44faba8390d213ae592fb0d56c5dfab152284e334d7cd6abd05799236e7aa6266edf81907c60404c57ee54c10a3a82fcc2a9146629b140 See also: https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources https://github.com/danefail/list/issues/47#issuecomment-456623996 -- Viktor.