June 2019 - dane-users - list.sys4.de

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

Proofpoint announces DANE support
by Knubben, B.S.J. (Bart) - Forum Standaardisatie 25 Jun '19

25 Jun '19

Hi, See: https://twitter.com/ProofpointJ/status/1143536219126677504 and also https://mobile.twitter.com/internet_nl/status/1143548855075651584 -- 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.

1 0

DANE plus wildcard record
by Rob McGee 16 Jun '19

16 Jun '19

Hi all, first post here. Hi Viktor and the sys4.de gang. I host a mailing list for a free software project with DANE enabled both ways. No need for secrecy there, it's Slackbuilds.org. One of my subscribers recently signed his or her zone, and sadly, has a wildcard A in that zone. Unfortunately at this point I do have to keep that zone name private, although offlist I'd tell it to someone I know and consider trustworthy to maintain the user's confidence. Oh, if you consult your dane.sys4.de logs for a bit ago, I suppose I already DID tell you the zone name. :) Starts with "a" and is in com. TLD. The checker reports "DNS lookup error for TLSA records: SERVFAIL", which is what I get on the named recursive resolver that Postfix is using, querying "_25._tcp.smtp.example.com./IN/TLSA". So Postfix is refusing to deliver, believing that there should be a TLSA. But AFAIK this user never published TLSA. The SOA MNAME host has disabled version.bind./CH/TXT lookups so I am not sure what software is in use, but having A for an invalid hostname (underscores not allowed in hostnames) would be a problem for BIND named, which by default would not allow that. But I don't know how that feature interacts with wildcard records. Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR. -- http://rob0.nodns4.us/

2 5

Update on stats 2019-05
by Viktor Dukhovni 02 Jun '19

02 Jun '19

Summary: The DANE domain count is now 1,149,012 The number of domains that return DNSSEC-validated replies in response to MX queries is 9,874,472. 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. Appeal: The handful of providers with long-term broken DNSSEC denial of existence are sadly making little progress to update their buggy DNS implementations. It would be really great if (at least): mijnhostingpartner.nl (Many broken NSEC3 RRSIGs) epik.com (Wildcards missing from NSEC chain) metaregistrar.nl (Wrong empty non-terminal handling) tiscomhosting.nl (Missing wildcard NSEC for NODATA response) dotserv.com (invalid NSEC chain order) movenext.nl (NSEC replies don't cover wildcard) nrdns.nl (Malformed NSEC3 or ServFail) binero.se (NSEC3 chain names returned as NSEC!) fixed their nameserver and/or zone provisioning code. While the O(10^3) affected domains are a small fraction of the O(10^7) signed domains, they are a much larger fraction of the signed domains for those particular providers. Appeal: The number of domains with neglected outdated TLSA records, has grown to ~500. PLEASE *monitor* your deployment, and implement a cert/key rollover process that does not (even temporarily) disrupt the validity of your certificate chain as compared to the published (cached) TLSA records: https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources If you're willing and able to help reach out to the operators of MX hosts with misconfigured TLSA RRsets, please get in touch. As of today I count 1,149,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: 705488 one.com 125798 transip.nl 97267 domeneshop.no 36238 active24.com 32475 vevida.com 24131 udmedia.de 15856 flexfilter.nl 12993 onebit.cz 12327 zxcs.nl 10961 bhosted.nl 5999 netzone.ch 5644 previder.nl 3795 ips.nl 3401 interconnect.nl 2481 provalue.nl 2287 nederhost.nl 1628 nmugroup.com 1574 yourdomainprovider.net 1320 hi7.de 1293 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). 5221 TOTAL 1758 DE, Germany 1065 US, United States 718 NL, Netherlands 383 FR, France 216 GB, United Kingdom 175 CZ, Czechia 116 CA, Canada 88 SG, Singapore 75 CH, Switzerland 71 SE, Sweden 54 DK, Denmark 43 IE, Ireland 43 AT, Austria 41 FI, Finland 36 AU, Australia 34 PL, Poland 34 BR, Brazil 26 RU, Russia 26 JP, Japan 23 IN, India IPv6 is still comparatively rare for MX hosts, and the top 20 countries by DANE MX host IPv6 GeoIP are: 1914 TOTAL 732 DE, Germany 304 NL, Netherlands 238 FR, France 155 US, United States 114 CZ, Czechia 74 GB, United Kingdom 39 SE, Sweden 33 CH, Switzerland 28 RU, Russia 28 CA, Canada 22 AT, Austria 18 IE, Ireland 14 NO, Norway 13 DK, Denmark 12 FI, Finland 10 AU, Australia 9 SI, Slovenia 9 IN, India 7 IT, Italy 6 SK, Slovakia There are 4392 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 6639. These cover 7077 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 245 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 129 are in recent (last 90 days of) reports: univie.ac.at ruhr-uni-bochum.de mailplus.nl gmx.at tu-darmstadt.de markteffectmail.nl transip.be tum.de minbzk.nl nic.br uni-erlangen.de ouderportaal.nl registro.br uni-muenchen.de overheid.nl gmx.ch unitybox.de pathe.nl open.ch unitymedia.de photofacts.nl anubisnetworks.com web.de photofactsacademy.nl fmc-na.com egmontpublishing.dk politie.nl gmx.com netic.dk previder.nl habr.com sitnet.dk rijksoverheid.nl hotelsinduitsland.com tilburguniversity.edu rotterdam.nl kpn.com zone.eu rvo.nl mail.com dovecot.fi ssonet.nl one.com ac-strasbourg.fr transip.nl solvinity.com insee.fr truetickets.nl t-2.com octopuce.fr utwente.nl telfort.com web200.hu uvt.nl trashmail.com comcast.net xs4all.nl xfinity.com dd24.net domeneshop.no xfinityhomesecurity.com dns-oarc.net handelsbanken.no xfinitymobile.com gmx.net uib.no active24.cz habramail.net webcruitermail.no atlas.cz hr-manager.net atelkamera.nu centrum.cz inexio.net aegee.org cuni.cz mpssec.net debian.org klubpevnehozdravi.cz procurios.net freebsd.org onebit.cz riseup.net gentoo.org smtp.cz t-2.net ietf.org virusfree.cz transip.net isc.org volny.cz transversal.net netbsd.org allsecur.de vevida.net openssl.org bayern.de xs4all.net ozlabs.org bund.de bhosted.nl samba.org elster.de bluerail.nl torproject.org fau.de boekwinkeltjes.nl asf.com.pt freenet.de corpoflow.nl deborla.pt gmx.de denhaag.nl moikrug.ru jpberlin.de dictu.nl handelsbanken.se lrz.de digid.nl minmyndighetspost.se mail.de hierinloggen.nl personligalmanacka.se mensa.de hr.nl skatteverket.se posteo.de intermax.nl govtrack.us Of the ~1.15 million domains, 2514 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 560. 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 1318. The top 10 name server operators with problem domains are: 537 mijnhostingpartner.nl 109 epik.com 40 metaregistrar.nl 34 tiscomhosting.nl 34 dotserv.com 33 movenext.nl 31 nrdns.nl 30 binero.se 29 domaincontrol.com 27 sylconia.net [ Sadly epik.com is back, after resolving all issues last month, it seems while the reported domains were resolved, the underlying systemic issue was not. ] 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. Eleven 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 key.com keybank.com bluehosting.host 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.

1 0