December 2019 - dane-users

Overview of outbound DANE for SMTP support
by Knubben, B.S.J. (Bart) - Forum Standaardisatie 26 May '21

26 May '21

Hi, We made the following overview of products/services with outbound DANE support (i.e. DANE verification). Any remarks/additions are welcome. I. Supported: - Postfix (since version 2.11.0, January 2014): http://www.postfix.org/TLS_README.html#client_tls_dane - Halon (since version 3.4-r2, November 2015): https://halon.io/dane and https://wiki.halon.io/DANE - OpenSSL (since version 1.1.0, August 2016): https://www.openssl.org/docs/manmaster/man3/SSL_CTX_dane_enable.html and https://www.openssl.org/docs/manmaster/man1/openssl-s_client.html - Cloudmark (since version 5.2, March 2017): https://blog.cloudmark.com/2017/03/27/dane-and-email-security/ - Exim (since version 4.91, April 2018): https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp… - Mail-in-a-Box (uses Postfix): https://github.com/mail-in-a-box/mailinabox/blob/master/security.md - ldns (uses OpenSSL): https://www.nlnetlabs.nl/documentation/ldns/dane_8h.html II. Requested: - Cisco: Bug ID: CSCuo87918 - [ Feature Request] TLS DANE Support for Email Security Appliance, https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuo87918/ - MS O365: https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/… and https://office365.uservoice.com/forums/289138-office-365-security-complianc… - Fortinet: https://fortinet.uservoice.com/forums/23797-fortipartner-feature-requests/s… - Protonmail: https://protonmail.uservoice.com/forums/284483-feedback/suggestions/3433882… and https://protonmail.uservoice.com/forums/284483-feedback/suggestions/1659360… BTW a simple outbound DANE test can be found on https://havedane.net. -- Best regards, Bart Knubben Dutch Standardisation Forum https://www.forumstandaardisatie.nl/content/english Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

5 6

Multiple Let's Encrypt X3 issuer certificates (same public key)
by Viktor Dukhovni 07 Dec '19

07 Dec '19

I'm seeing in active use two distinct issuer certificates for the Let's Encrypt Authority X3 CA: Issuer CommonName = DST Root CA X3 Issuer Organization = Digital Signature Trust Co. notBefore = 2016-03-17T16:40:46Z notAfter = 2021-03-17T16:40:46Z Subject CommonName = Let's Encrypt Authority X3 Subject Organization = Let's Encrypt pkey sha256: 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 Issuer CommonName = ISRG Root X1 Issuer Organization = Internet Security Research Group notBefore = 2016-10-06T15:43:55Z notAfter = 2021-10-06T15:43:55Z Subject CommonName = Let's Encrypt Authority X3 Subject Organization = Let's Encrypt pkey sha256: 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 While they share the same public key, and therefore the same matching "2 1 1" TLSA record, they unsurprisingly don't have the same full certificate "2 0 1" fingerprint. This is a good opportunity to remind users that you should not pin the "2 0 1" or "2 0 2" fingerprints for any public CAs (including Let's Encrypt) in your TLSA records. If you don't control the CA, it is too easy to be surprised by an unexpected change in the issuer certificate (new root, updated expiry, ...). While of course the CA can and sometimes will employ a new public key, key changes are less frequent, and it is more prudent to use "2 1 1" rather than "2 0 1" records (when not just using "3 X X" records). https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-… If you've not yet seen: https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources please do look over the materials there. In particular, implement *monitoring* for your server TLSA records making sure these match the certificate chain, and employ a resilient rollover scheme. If you're one of the brave users with certificates for multiple algorithms (say both RSA and ECDSA), make sure your TLSA records match the chains for both algorithms. -- Viktor.

1 0

Update on stats 2019-11
by Viktor Dukhovni 02 Dec '19

02 Dec '19

Summary: The DANE domain count is now 1,714,271. This is a substantial increase over last month, despite the data feeds from SIDN (.NL) and Farsight Security (passive DNS across all TLDs) not being ready in time for this month-end summary. The count will likely rise again, once those data sets are processed. The number of domains that return DNSSEC-validated replies in response to MX queries is 10,448,578. This is a large increase over last month when the total was 10,133,312. Thus DANE TLSA is deployed on ~16.41% of domains with DNSSEC. This month the DANE domain count for one.com is larger than one million. Congratulations and thanks again to one.com! Also adoption of ECDSA P-256 (algorithm 13) continues to grow, and the number of domains using P-256 KSKs has almost reached parity with RSA-SHA256 (algorithm 8), which is just ahead for now, but likely not for very much longer. https://stats.dnssec-tools.org/#parameter 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,714,271 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: 1,013,231 one.com 130,768 transip.nl 98,944 domeneshop.no 88,010 loopia.se 37,102 active24.com 31,595 vevida.com 28,681 antagonist.nl 26,461 web4u.cz 24,373 udmedia.de 17,099 bhosted.nl 16,414 zxcs.nl 15,480 flexfilter.nl 13,341 onebit.cz 8,283 protonmail.ch 5,982 netzone.ch 5,567 previder.nl 4,658 mailplatform.eu 3,563 ips.nl 3,187 interconnect.nl 2,852 zonemx.eu 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). 5862 TOTAL 1964 DE, Germany 1166 US, United States 852 NL, Netherlands 461 FR, France 229 GB, United Kingdom 189 CZ, Czechia 118 CA, Canada 96 SG, Singapore 81 CH, Switzerland 77 SE, Sweden 64 DK, Denmark 58 FI, Finland 46 IE, Ireland 41 AT, Austria 40 AU, Australia 39 JP, Japan 38 PL, Poland 28 RU, Russia 28 BR, Brazil 24 IT, Italy IPv6 is less common than IPv4 for MX hosts, and the top 20 countries by DANE MX host IPv6 GeoIP are: 3009 TOTAL 1248 DE, Germany 503 US, United States 434 NL, Netherlands 247 FR, France 112 CZ, Czechia 89 GB, United Kingdom 39 SE, Sweden 36 SG, Singapore 31 CH, Switzerland 30 RU, Russia 29 JP, Japan 26 CA, Canada 21 AT, Austria 19 IE, Ireland 14 SI, Slovenia 14 DK, Denmark 13 NO, Norway 12 ID, Indonesia 12 BR, Brazil 11 FI, Finland There are 4918 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 7570. These cover 8456 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 293 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 148 are in recent (last 90 days of) reports: univie.ac.at lrz.de minbzk.nl gmx.at mail.de mm1.nl nic.br posteo.de ouderportaal.nl registro.br ruhr-uni-bochum.de overheid.nl buymyweedonline.ca tum.de parlement.nl gmx.ch uni-erlangen.de pathe.nl open.ch uni-muenchen.de photofacts.nl protonmail.ch unitybox.de photofactsacademy.nl altospam.com unitymedia.de politie.nl anubisnetworks.com web.de previder.nl clubedominante.com egmontpublishing.dk rijksoverheid.nl fmc-na.com netic.dk ru.nl gmx.com star.dk schoudercom.nl habr.com tilburguniversity.edu schuurman-schoenen.nl hotelsinduitsland.com web200.eu ssonet.nl ingthink.com zone.eu truetickets.nl kpn.com ac-strasbourg.fr tweedekamer.nl mail.com kangouroukids.fr uitgeverijpica.nl mammoetmail.com octopuce.fr utwente.nl one.com web200.hu uvt.nl primexbt.com 247superhost.net xs4all.nl protonmail.com comcast.net domeneshop.no societe.com dns-oarc.net handelsbanken.no solvinity.com gmx.net uib.no t-2.com habramail.net webcruitermail.no telfort.com hr-manager.net atelkamera.nu trashmail.com inexio.net debian.org xfinity.com mpssec.net freebsd.org xfinityhomesecurity.com procurios.net gentoo.org xfinitymobile.com riseup.net ietf.org active24.cz t-2.net isc.org atlas.cz transip.net mailbox.org centrum.cz vevida.net netbsd.org cuni.cz xs4all.net openssl.org itesco.cz 50plusbeurs.nl ozlabs.org klubpevnehozdravi.cz belastingdienst.nl samba.org onebit.cz bhosted.nl torproject.org optimail.cz billybird.nl whatpulse.org server4u.cz bluerail.nl moikrug.ru smtp.cz boozyshop.nl boplatssyd-automail.se virusfree.cz corpoflow.nl handelsbanken.se volny.cz denhaag.nl loopia.se web4u.cz digid.nl minmyndighetspost.se bayern.de digistate.nl personligalmanacka.se bund.de ezorg.nl skatteverket.se elster.de fontys.nl theletter.se fau.de hr.nl govtrack.us freenet.de hro.nl ru.ac.za gmx.de intermax.nl jpberlin.de mailplus.nl Of the ~1.71 million domains, 3220 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 462. 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 email outages, 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://mail.sys4.de/pipermail/dane-users/2018-February/000440.html 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 1435. The top 10 name server operators with problem domains are: 400 mijnhostingpartner.nl 295 domaincontrol.com (a.k.a. Godaddy, new this month) 89 egensajt.se 53 movenext.nl 43 metaregistrar.nl 33 tiscomhosting.nl 30 eurodns.com 28 nrdns.nl 26 hostnet.nl 19 sylconia.net 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. Twelve of the domains all whose nameservers have broken denial of existence appear in the last 120 days of Google transparency reports: coren-sp.gov.br trt01.gov.br trtrio.gov.br trt1.jus.br trtrj.jus.br groupconcorde.com kineticcu.com xoriant.com xpressbillpay.com mobily.com.sa sauditelecom.com.sa bog.gov.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.

3 8