January 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 2019-12
by Viktor Dukhovni 01 Jan '20

01 Jan '20

Summary: The DANE domain count is now 1,734,012. The number of domains that return DNSSEC-validated replies in response to MX queries is 10,715,677. This is another large increase over last month when the total was 10,448,578. Thus DANE TLSA is deployed on ~16.18% of domains with DNSSEC. Also adoption of ECDSA P-256 (algorithm 13) continues to grow, and the number of domains using P-256 KSKs has now surpassed RSA-SHA256 (algorithm 8) to become the most widely used DNSSEC algorithm. See: https://stats.dnssec-tools.org/#parameter Happy New Year! Great progress over the past twelve months, Last year's December totals were 774,820 DANE SMTP domains and 8,878,369 DNSSEC-signed domains.] 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,734,012 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: 1019882 one.com 132965 transip.nl 99844 domeneshop.no 88024 loopia.se 37425 active24.com 31555 vevida.com 29476 antagonist.nl 26738 web4u.cz 24646 udmedia.de 18342 zxcs.nl 17227 bhosted.nl 15468 flexfilter.nl 13505 onebit.cz 8765 protonmail.ch 5886 netzone.ch 5632 previder.nl 4707 mailplatform.eu 4116 soverin.net 3548 ips.nl 3239 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). 6015 TOTAL 1998 DE, Germany 1209 US, United States 892 NL, Netherlands 480 FR, France 229 GB, United Kingdom 194 CZ, Czechia 128 CA, Canada 82 CH, Switzerland 79 SG, Singapore 74 SE, Sweden 67 DK, Denmark 54 FI, Finland 46 IE, Ireland 45 AT, Austria 38 PL, Poland 38 JP, Japan 38 AU, Australia 30 RU, Russia 26 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: 3103 TOTAL 1275 DE, Germany 540 US, United States 463 NL, Netherlands 261 FR, France 105 CZ, Czechia 90 GB, United Kingdom 41 SE, Sweden 33 SG, Singapore 30 CH, Switzerland 28 JP, Japan 28 CA, Canada 24 AT, Austria 18 IE, Ireland 17 RU, Russia 15 DK, Denmark 14 SI, Slovenia 13 NO, Norway 13 ID, Indonesia 12 FI, Finland 12 BR, Brazil There are 5053 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 7743. These cover 8629 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 297 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 147 are in recent (last 90 days of) reports: univie.ac.at jpberlin.de jasperalblas.nl gmx.at lrz.de mailplus.nl register.bg mail.de minbzk.nl nic.br posteo.de mindef.nl registro.br ruhr-uni-bochum.de mm1.nl buymyweedonline.ca tum.de ouderportaal.nl gmx.ch uni-erlangen.de overheid.nl open.ch uni-muenchen.de pathe.nl protonmail.ch unitybox.de photofacts.nl anubisnetworks.com unitymedia.de photofactsacademy.nl clubedominante.com web.de politie.nl gmx.com egmontpublishing.dk previder.nl habr.com netic.dk rijksoverheid.nl hotelsinduitsland.com star.dk ru.nl ingthink.com tilburguniversity.edu rvo.nl kpn.com rediris.es schoudercom.nl mail.com uv.es schuurman-schoenen.nl mammoetmail.com komfortkasse.eu ssonet.nl one.com web200.eu truetickets.nl primexbt.com zone.eu uvt.nl protonmail.com ac-strasbourg.fr xs4all.nl societe.com kangouroukids.fr domeneshop.no solvinity.com octopuce.fr handelsbanken.no t-2.com web200.hu uib.no telfort.com comcast.net webcruitermail.no trashmail.com dns-oarc.net atelkamera.nu xfinity.com gmx.net debian.org xfinityhomesecurity.com habramail.net freebsd.org xfinitymobile.com hr-manager.net gentoo.org active24.cz inexio.net ietf.org atlas.cz mpssec.net isc.org centrum.cz procurios.net lazarus-ide.org cuni.cz riseup.net mailbox.org itesco.cz t-2.net netbsd.org klubpevnehozdravi.cz transip.net openssl.org krypton.cz vevida.net ozlabs.org onebit.cz xs4all.net samba.org optimail.cz belastingdienst.nl torproject.org server4u.cz bhosted.nl whatpulse.org smtp.cz billybird.nl moikrug.ru virusfree.cz bluerail.nl boplatssyd-automail.se volny.cz boozyshop.nl handelsbanken.se web4u.cz corpoflow.nl loopia.se bayern.de denhaag.nl minmyndighetspost.se bund.de dictu.nl personligalmanacka.se elster.de digid.nl skatteverket.se fau.de ezorg.nl theletter.se freenet.de fontys.nl govtrack.us gmx.de intermax.nl ru.ac.za Of the ~1.73 million domains, 3382 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 426. 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 1372. The top 11 name server operators with problem domains are: 347 registrar-servers.com (new this month, fix expected in days) 221 mijnhostingpartner.nl (varies between 200 and 500+) 95 egensajt.se 62 movenext.nl 59 eurodns.com 47 metaregistrar.nl 32 tiscomhosting.nl 29 nrdns.nl 26 hostnet.nl 24 ebola.cz 20 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. Nine 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 flytoyourheart.com topdecorationworld.com mobily.com.sa 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.

1 0