March 2020 - 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

Deprecating DNSSEC algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1)
by Viktor Dukhovni 06 Apr '20

06 Apr '20

Given the recent advances in SHA-1 collision attacks, https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html https://sha-mbles.github.io/ it is time to deprecate the remaining DNSSEC SHA-1 based DNSKEY algorithms. If you've deployed inbound DANE by publishing signed TLSA records for your MX hosts, but your underlying DNSSEC deployment uses DNSKEY algorithms other than 13 (recommended), 8 (popular) or 10 (fine, though not widely used), then you should migrate your domains to algorithm 13 (preferred) or 8. This should be done while the attacks are still costly, and have somewhat limited applicability. Algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) may not be quite dead, but they are significantly wounded. If/when you do decide to switch algorithms, please perform the migration with care. Algorithm rollovers can be tricky. The basic process is: 1. Publish and activate a ZSK for the new algorithm. Your zone should now be double-signed, which each record having two RRSIGs. Don't forget to bump the SOA. 2. Wait for at least 2 maximum TTLs after the primary and all secondary nameservers have started serving the updated zone. 3. Publish and activate a KSK for the new algorithm. This KSK adds a second signature to your zone apex DNSKEY RRset. Don't forget to bump the SOA. 4. Wait for at least 2 maximum TTLs after the primary and all secondary nameservers have started serving the updated zone. 5. Arrange for the parent zone to publish DS records matching the new KSK in addition to DS RRs matching the KSKs for the previous algorithm. 6. Wait for at least 2 parent zone TTLs after all nameservers for the parent zone have started serving the new DS RRset. 7. Request deletion of the DS RRs for the old algorithm. 8. Wait for at least 2 parent zone TTLs after all nameservers for the parent zone have starting serving the new DS RRset. 9. Remove the old KSKs from your DNSKEY RRset after checking that the DS RRset with just the new algorithm matches your new KSK. 10. Wait for at least 2 maximum TTLs after the primary and all secondary nameservers have started serving the updated zone. 11. Deactivate the old ZSKs leaving the zone signed only under the new ZSKs. 12. Wait for at least 2 maximum TTLs after the primary and all secondary nameservers have started serving the updated zone. 13. Remove the old ZSKs from your DNSKEY RRset. The reason for all this is to maintain the followin invariants: A. Each algorithm mentioned in the parent zone DS RRset must have a matching KSK in the zone's DNSKEY RRset. B. Each KSK algorithm appearing in the zone's DNSKEY RRset must have a corresponding ZSK signature for each record in the zone. Therefore, new algorithms are introduced from the ZSK up, while old algorithms are removed from the DS RRset down. The various "wait" steps are needed to ensure that resolvers using cached data are able to validate your changing zone at all times. Presently, the DANE survey database shows ~230 thousand domains using algorithms 5 and 7. It would be great to see this number substantially reduced over the coming months. -- Viktor.

5 8

Update on stats 2020-02
by Viktor Dukhovni 01 Mar '20

01 Mar '20

Summary: The DANE domain count is now 1,842,179. The number of domains that return DNSSEC-validated replies in response to MX queries is 10,837,476. Thus DANE TLSA is deployed on ~17.00% 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,842,179 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 below. 1039151 one.com 135237 transip.nl 100341 domeneshop.no 88535 loopia.se 68917 infomaniak.ch 37835 active24.com 31227 vevida.com 30345 antagonist.nl 26692 web4u.cz 24813 udmedia.de 22509 zxcs.nl 17374 bhosted.nl 15308 flexfilter.nl 13690 onebit.cz 9518 protonmail.ch 5814 netzone.ch 5575 previder.nl 5163 soverin.net 4756 mailplatform.eu 4321 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). 6251 TOTAL 2084 DE, Germany 1246 US, United States 896 NL, Netherlands 549 FR, France 256 GB, United Kingdom 201 CZ, Czechia 153 CA, Canada 85 CH, Switzerland 83 SG, Singapore 78 SE, Sweden 69 DK, Denmark 46 AT, Austria 44 IE, Ireland 43 JP, Japan 39 AU, Australia 31 BR, Brazil 27 RU, Russia 26 PL, Poland 25 IT, Italy 23 IN, India IPv6 is less common than IPv4 for MX hosts, and the top 20 countries by DANE MX host IPv6 GeoIP are: 3176 TOTAL 1311 DE, Germany 531 US, United States 453 NL, Netherlands 263 FR, France 112 CZ, Czechia 98 GB, United Kingdom 41 SE, Sweden 35 SG, Singapore 34 AT, Austria 33 CH, Switzerland 32 JP, Japan 32 CA, Canada 31 RU, Russia 17 IE, Ireland 16 DK, Denmark 14 SI, Slovenia 13 NO, Norway 13 AU, Australia 12 ID, Indonesia 12 BR, Brazil There are 5296 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 organizations deploying DANE SMTP. The number of published MX host TLSA RRsets found is 8054. These cover 8964 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 322 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 155 are in recent (last 90 days of) reports: univie.ac.at jpberlin.de minbzk.nl gmx.at kabelmail.de mindef.nl register.bg lrz.de mm1.nl nic.br mail.de ouderportaal.nl registro.br mailserver4.de overheid.nl buymyweedonline.ca posteo.de pathe.nl gmx.ch ruhr-uni-bochum.de photofacts.nl infomaniak.ch tum.de politie.nl open.ch uni-erlangen.de previder.nl protonmail.ch uni-muenchen.de rijksoverheid.nl anubisnetworks.com unitybox.de ru.nl clubedominante.com unitymedia.de rvo.nl fmc-na.com web.de schoudercom.nl gmx.com egmontpublishing.dk schuurman-schoenen.nl habr.com netic.dk ssonet.nl hotelsinduitsland.com star.dk truetickets.nl infomaniak.com tilburguniversity.edu uvt.nl ingthink.com emta.ee xs4all.nl kpn.com lugeja.ee zorgmail.nl leszexpertsfle.com rmit.ee domeneshop.no mail.com rediris.es handelsbanken.no mammoetmail.com uv.es uib.no one.com web200.eu webcruitermail.no primexbt.com zone.eu atelkamera.nu protonmail.com ac-strasbourg.fr goget.nu solvinity.com compagnie-des-sens.fr aegee.org t-2.com octopuce.fr debian.org telfort.com web200.hu freebsd.org trashmail.com comcast.net gentoo.org vitstore.com dns-oarc.net ietf.org xfinity.com gmx.net isc.org xfinityhomesecurity.com habramail.net lazarus-ide.org xfinitymobile.com hr-manager.net mailbox.org active24.cz inexio.net netbsd.org atlas.cz mpssec.net openssl.org centrum.cz procurios.net ozlabs.org cuni.cz riseup.net samba.org itesco.cz t-2.net slackbuilds.org klubpevnehozdravi.cz transip.net torproject.org krypton.cz vevida.net whatpulse.org onebit.cz xs4all.net asf.com.pt optimail.cz xworks.net moikrug.ru smtp.cz belastingdienst.nl boplatssyd-automail.se virusfree.cz bhosted.nl handelsbanken.se volny.cz bluerail.nl loopia.se web4u.cz boozyshop.nl minmyndighetspost.se bayern.de corpoflow.nl personligalmanacka.se bund.de dictu.nl skatteverket.se elster.de digid.nl theletter.se fau.de intermax.nl govtrack.us freenet.de jasperalblas.nl ru.ac.za gmx.de mailplus.nl Of the ~1.84 million domains, 4424 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 466. Some of these have additional MX hosts that don't have broken TLSA records, so mail can still arrive via the remaining MX hosts. 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://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP… https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-… https://mail.sys4.de/pipermail/dane-users/2017-August/000417.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 1846. The top 13 name server operators with problem domains are: 482 registrar-servers.com (count still growing slowly) 348 mijnhostingpartner.nl (operator expects a fix "before long") 275 axc.nl (new this month :-( ) 82 egensajt.se 64 movenext.nl 56 ebola.cz 46 metaregistrar.nl 30 tiscomhosting.nl 27 hostnet.nl 23 infracom.nl 22 cdmon.net 20 sylconia.net 17 is.nl 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. Nine (same as last month) of the domains all whose nameservers have broken denial of existence appear in the last 120 days of Google transparency reports: trt01.gov.br trtrio.gov.br trt1.jus.br trtrj.jus.br flytoyourheart.com topdecorationworld.com mobily.com.sa sauditelecom.com.sa threadteaching.co.uk -- 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