From ietf-dane at dukhovni.org Tue Aug 1 01:30:08 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 31 Jul 2017 23:30:08 +0000 Subject: Update on stats 2017-07 (infracom.nl DNS resolved) Message-ID: <20170731233008.GA7328@mournblade.imrryr.org> Summary: Mostly the same as last month, with significant progress on the DNS front, as infracom.nl's nameservers now handle TLSA lookups correctly (they now respond with valid denial of existence or actual TLSA records as appropriate). The number of DANE-enabled domains that have also been sighted on Google's email transparency report has increased from 111 to 114, while the number of DNS zones with TLSA-enabled MX hosts has increased from 2615 to 2668. The overall count has increased from 171460 to 171738. NOTE 1: This month I've begun the transition to new backend code for the survey. The main visible change is that MX hosts that are, despite RFC requirements, CNAMEs for the real underlying host are no longer excluded from the survey. This leads to a small bump in the reported domain count (+81) that is due to the code change. NOTE 2: The survey only includes domains at least of whose "primary" MX hosts has secure TLSA records. The previous survey code skipped past any MX hosts that provably (DNSSEC-validated) had neither IPv4 nor IPv6 addresses (secure NXDOMAIN or NODATA). The new survey code makes this more difficult, and I may at some point stop including these domains (613 at last count). As of today I count 171738 domains with correct DANE TLSA records for SMTP. As expected the bulk of the DANE domains are hosted the handful of DNS/hosting providers who've enabled DANE support in bulk for the domains they host. The top 10 MX host providers by domain count are: 69168 domeneshop.no 60171 transip.nl 18330 udmedia.de 6611 bhosted.nl 1809 nederhost.net 1341 yourdomainprovider.net -- (includes former networking4all.net domains) 1002 ec-elements.com 512 core-networks.de 378 omc-mail.com 342 bit.nl The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.de. There are 2668 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. Alternatively, a similar number is seen in the count (2910) of distinct MX host server certificates that support the same ~171000 domains (this month the count includes all the MX hosts, rather just a single primary MX). A related number is 3797 matching TLSA RRsets found for MX host TCP port 25. These certificates are vended by 3951 distinct MX hosts (some of which clearly employ a shared certificate). The number of domains that at some point were listed in Gmail's email transparency report is 114 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 56 are in recent reports: gmx.at lrz.de otvi.nl nic.br mail.de ouderportaal.nl registro.br posteo.de overheid.nl gmx.ch ruhr-uni-bochum.de pathe.nl open.ch tum.de uvt.nl anubisnetworks.com uni-erlangen.de xs4all.nl gmx.com unitymedia.de domeneshop.no mail.com web.de webcruitermail.no solvinity.com tilburguniversity.edu debian.org trashmail.com enron.email freebsd.org xfinity.com octopuce.fr gentoo.org xfinityhomesecurity.com comcast.net ietf.org bayern.de dd24.net isc.org bund.de gmx.net netbsd.org elster.de hr-manager.net openssl.org fau.de mpssec.net samba.org freenet.de t-2.net torproject.org gmx.de xs4all.net asf.com.pt jpberlin.de asp4all.nl Of the ~172000 domains, 888 have "partial" TLSA records, that cover only a subset of the 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 101. Below is a list of the 55 underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: mail.dipietro.id.au h-hibernia.olnis-net.de dorothy.goldenhairdafo.net eumembers.stansoft.bg mx1.spamsponge.de mail.iaelu.net mx.delphij.com mail.stmartin-schwabach.de hs.kuzenkov.net mail.digitalwebpros.com mx.thorko.de oostergo.net demo.liveconfig.com smtp.flipmail.es cinnamon.nl intranet.nctechcenter.com mail.0pc.eu mail.e-rave.nl ny-do.pieterpottie.com palinet.eu mail.jekuiken.nl diablo.sgt.com mx.quentindavid.fr mail.myzt.nl tusk.sgt.com servmail.fr bounder.steelyard.nl mx1.wittsend.com mail.nonoserver.info mail.abanto-zierbena.org mx.bels.cz mail.bax.is beerstra.org gaia.nfx.cz mail.laukas.lt eumembers.datacentrix.org mail.b0red.de mx.datenknoten.me smtp3.amadigi.ovh mail.bg-netzwerk.de mx.giesen.me mail.pasion.ro mail.denniseffing.de completelyunoriginal.moe puggan.se mutt.lsexperts.de mail.castleturing.net mail.rostit.se mail.manima.de horse.cherrypet.net protector.rajmax.si www.mtg.de anubis.delphij.net h-hibernia.olnis-Net.de goldenhairdafo.net The number of domains with bad DNSSEC support is 374. The top 10 DNS providers with problem domains are: 66 jsr-it.nl 26 active24.cz 25 tiscomhosting.nl 19 firstfind.nl 16 rdw.nl 9 metaregistrar.nl 9 ignum.com 8 ovh.net 8 loopia.se 7 rootdomains.nl Around 46 of the broken domains have at least one working nameserver, and so are email-reachable, given enough retries. Only 5 of the DNS-broken domains appear in historical Google Email transparency reports: tiviths.com.br tre-sp.jus.br trt1.jus.br trtrj.jus.br tse.jus.br The associated DNS lookup issues are: _25._tcp.mx.tiviths.com.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.mx.tiviths.com.br/dnssec/ _25._tcp.mx1.trt1.jus.br. IN TLSA ? ; zone signature failure: http://dnsviz.net/d/_25._tcp.mx1.trt1.jus.br/dnssec/ _25._tcp.mx1.trtrj.jus.br. IN TLSA ? ; zone signature failure: http://dnsviz.net/d/_25._tcp.mx1.trtrj.jus.br/dnssec/ _25._tcp.dexter.tse.jus.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.dexter.tse.jus.br/dnssec/ _25._tcp.lalavava.tse.jus.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.lalavava.tse.jus.br/dnssec/ _25._tcp.mandark.tse.jus.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.mandark.tse.jus.br/dnssec/ [ See , Much of the TLSA non-response issue seems to be related to a "feature" of Arbor Networks firewalls, that enables droping of DNS requests for all but the most common RRtypes. Do not make the mistake of enabling this firewall "feature". ] The oldest outstanding DNS issue is another SOA signature issue at truman.edu dating back to Nov/2014: http://dnsviz.net/d/_25._tcp.barracuda.truman.edu/VGzORw/dnssec/ I hope some day soon they'll start missing email they care about and take the time to resolve the problem. -- Viktor. From cs at sys4.de Thu Aug 31 09:36:10 2017 From: cs at sys4.de (Carsten Strotmann) Date: Thu, 31 Aug 2017 07:36:10 +0000 Subject: DANE for SMTP and TLS certificate agility Message-ID: <86bmmw89zp.fsf@emacs.strotmann.de> Below a little text about TLS certificate agility and some pitfalls herein (thanks to Viktor and Patrick for input and review): The Transport Layer Protocol (TLS) supports the introduction of new key algorithms for x509 certificates. For a long time, keys based on the RSA algorithm were the only available choice. Nowadays, TLS also permits keys based on elliptic curve algorithms such as ECDSA. Other, new algorithms might follow in the future. Modern algorithms promise same or better security with less CPU usage and smaller key sizes. This makes the new algoritms interesting for operators of TLS secured services. However older software (on client or peer server side) might not support and understand the newer algorithms, so both the new and the old need be configured for some transition time. Ideally, both communicating endpoints will negotiate the best algorithm (in terms of security and performance) supported by both sides. The scheme of supporting multiple certificate key algorithms is called certificate agility. Care must be taken when multiple key algorithms are used in a TLS setup together with DNS-based Authentication of Named-Entities (DANE) as documented in RFC 7672 ([https://tools.ietf.org/html/rfc7672.html]). With SMTP-DANE, data authenticating the TLS certificates (the hashes of TLS certificate, hashes of the public key, or the full certificates) are stored in DNS, secured by DNSSEC. Upon connection, a delivering mail-server (MTA) will recieve the certificate chain from the destination MTA and will try to validate this certificate chain via the data stored in DNS as one or more TLSA resource records. The TLSA records contain either information on the leaf-node certificates (called DANE-EE(3)) or information about the certification authority (DATE-TA(2)). With DANE-EE(3) and TLS certificate agility in use, each distinct certificate that is configured on the server side does require it's own TLSA record containing either the hash of the certificate, hash of the public key of the certificate or the certificate itself. With DANE-TA(2), multiple TLSA-Records are only needed if the certificates are issued by different certification authorities (care must be taken to compare the CA keys in the certificate chain, as certain CA companies or "brands" are using different certificate authorities to sign x509 certificates). The postfix mail server supports certificate agility, in the example below two certificates are configured, one based on RSA keys, and a 2nd certificate using ECDSA keys: ,---- | # RSA certificate configuration | smtpd_tls_key_file=/etc/postfix/tls/rsa-key.pem | smtpd_tls_cert_file=/etc/postfix/tls/rsa-cert.pem | # ECDSA certificate configuration | smtpd_tls_eckey_file=/etc/postfix/tls/ecdsa-key.pem | smtpd_tls_eccert_file=/etc/postfix/tls/ecdsa-cert.pem `---- This configuration requires two separate DANE-EE(3) TLSA records in DNS, one for RSA and one for the ECDSA certificate. If both certifcates are issued from the same CA, only one DANE-TA(2) TLSA record is required. OpenSSL 1.0.x does not handle multiple chain files gracefully, and so both certificate chain files need to contain all the issuer CA certificates needed to validate either end-entity (leaf) certificate. This is fixed in OpenSSL 1.1.0. The selection of which certificate algorithm to use is based on the TLS handshake. Older TLS software prefers RSA over ECDSA, while some more modern software will have a preference for ECDSA. Today most DANE commandline tools (ldns-dane, gnutls-cli ...), as well as online DANE services such as the DANE SMTP Validator ([https://dane.sys4.de]), are only testing one certificate (based on the preference or configuration of the underlying TLS library used to implement the tools). A missing TLSA record can go unnoticed but can lead to rejection of mail. The DANE SMTP Validator will be updated to check all possible TLS certificate key algorithms. --- Carsten Strotmann From ietf-dane at dukhovni.org Thu Aug 31 17:55:46 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 31 Aug 2017 15:55:46 +0000 Subject: DANE for SMTP and TLS certificate agility In-Reply-To: <86bmmw89zp.fsf@emacs.strotmann.de> References: <86bmmw89zp.fsf@emacs.strotmann.de> Message-ID: <20170831155546.GQ3322@mournblade.imrryr.org> On Thu, Aug 31, 2017 at 07:36:10AM +0000, Carsten Strotmann wrote: > Below a little text about TLS certificate agility and some pitfalls > herein (thanks to Viktor and Patrick for input and review): Thanks for this post. Just wanted to mention that the concern about TLSA records matching only the RSA certificate chain and not the ECDSA certificate chain of an MX host is not just "theoretical". I've so far found two MX hosts of live domains that have both RSA and ECDSA chains deployed, but the TLSA records match only the RSA chain. As more users get adventurous and start deploying ECDSA, this problem is likely to become more frequent, if we don't manage to raise awareness. So this thread is a first step in that direction. A new (improved :-)) DANE scanner I've written in Haskell (the old one is in Perl) prefers ECDSA over RSA, and so is starting to find the misconfigured MX hosts that are missing the TLSA RRs needed to match the ECDSA chain. Don't forget that even "3 1 1", which matches only the public key and not the full certificate, still won't match both an RSA and an ECDSA server certificate, as, of course, the RSA and ECDSA public keys are different (not only in the raw key bits, but also in the ASN.1 OIDs that indicate the key type, the DANE TLSA public key hash covers not only the key and any key parameters, but also the key type OID). -- Viktor. From ietf-dane at dukhovni.org Thu Aug 31 22:40:38 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 31 Aug 2017 20:40:38 +0000 Subject: Update on stats 2017-08 Message-ID: <20170831204038.GA29327@mournblade.imrryr.org> Summary: Mostly the same as last month, but new code made possible more comprehensive coverage of domains with DNS issues. As a result, the number of reported DNS issues has increased by almost 75%. This is not an actual surge in DNS problems, rather just better reporting of the existing (still improving) landscape. The number of DANE-enabled domains that have also been sighted on Google's email transparency report has increased from 114 to 115, while the number of DNS zones with TLSA-enabled primary MX hosts has increased from 2668 to 2708. The domain count has increased from 171738 to 172205. A new type of TLSA record mismatch is starting to show up, so far on just two MX hosts. Their RSA certificate chains match their TLSA records, but their ECDSA certificate chains do not: https://mail.sys4.de/pipermail/dane-users/2017-August/000416.html https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html As of today I count 172205 domains with correct DANE TLSA records for SMTP. As expected the bulk of the DANE domains are hosted by the handful of DNS/hosting providers who've enabled DANE support in bulk for the domains they host. The top 10 MX host providers by domain count are: 68968 domeneshop.no 60617 transip.nl 18365 udmedia.de 6576 bhosted.nl 1809 nederhost.net 1331 yourdomainprovider.net 1003 ec-elements.com 517 core-networks.de 378 omc-mail.com 326 bit.nl The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, especially .no/.nl/.de. There are 2708 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. Alternatively, a similar number is seen in the count (2933) of distinct MX host server certificates that support the same ~172000 domains. A related number is 3585 matching TLSA RRsets found SMTP MX hosts. These cover 3708 distinct MX hosts (some of which clearly employ a shared certificate). The number of domains that at some point were listed in Gmail's email transparency report is 115 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 59 are in recent reports: gmx.at jpberlin.de ouderportaal.nl travelbirdbelgie.be lrz.de overheid.nl nic.br mail.de pathe.nl registro.br posteo.de xs4all.nl gmx.ch ruhr-uni-bochum.de domeneshop.no open.ch tum.de webcruitermail.no switch.ch uni-erlangen.de debian.org anubisnetworks.com unitymedia.de freebsd.org gmx.com web.de gentoo.org mail.com egmontpublishing.dk ietf.org solvinity.com enron.email isc.org trashmail.com octopuce.fr netbsd.org xfinity.com comcast.net openssl.org xfinityhomesecurity.com dd24.net samba.org bayern.de gmx.net torproject.org bund.de hr-manager.net asf.com.pt elster.de mpssec.net minmyndighetspost.se fau.de t-2.net skatteverket.se freenet.de xs4all.net t-2.si gmx.de asp4all.nl Of the ~172000 domains, 811 have "partial" TLSA records, that cover only a subset of the 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 111. Below is a list of the 69 underlying MX hosts that serve these domains and whose TLSA records don't match reality: Hall of Shame: mail.dipietro.id.au mutt.lsexperts.de wfbrace.net eumembers.stansoft.bg mail.manima.de mx2.wfbrace.net mail.gna.ch mx1.spamsponge.de mx2.cbrace.nl andbraiz.com mx.thorko.de mx3.cbrace.nl mail.digitalwebpros.com mail.0pc.eu cinnamon.nl mail.itsmine.com webmail.kassoft.eu smtp1.gblt.nl demo.liveconfig.com mx.quentindavid.fr mail.initfour.nl mx04.mykolab.com servmail.fr smtp1.lococensus.nl intranet.nctechcenter.com upc.dircon.hu mail.myzt.nl ny-do.pieterpottie.com mail.demongeot.info nuj-netherlands.nl ma.qbitnet.com mail.nonoserver.info mx2.nuj-netherlands.nl diablo.sgt.com kd2.io mail.solarisinternetgroep.nl tusk.sgt.com node2.mxbackup.io bounder.steelyard.nl stmics01.smia-automotive.com mail.laukas.lt vanderbijlict.nl stmics02.smia-automotive.com mx.datenknoten.me mail.abanto-zierbena.org erg.verweg.com mx.giesen.me beerstra.org mx.bels.cz rootbox.me smtp.copi.org gaia.nfx.cz lima.ahrain.net eumembers.datacentrix.org mail.seslost.cz mail.castleturing.net smtp3.amadigi.ovh mail.3c7.de horse.cherrypet.net mail.pasion.ro mail.afaul.de mail.efflam.net mail.familie-sander.rocks awesome-mail.de hs.kuzenkov.net mail.rostit.se mail.denniseffing.de oostergo.net protector.rajmax.si The number of domains with bad DNSSEC support is 649. Most of the increase is from accenture.com domains, almost all likely parked, so the actual impact on email delivery is probably small to none. The top 10 name server operators with problem domains are: 145 accenture.com 61 jsr-it.nl 26 tiscomhosting.nl 26 active24.cz 21 firstfind.nl 18 bradesco.com.br 17 usda.gov 10 rotterdam.nl 10 loopia.se 10 fde.dk Around 79 of the broken domains have at least one working nameserver, and so are email-reachable, given enough retries. Only 5 of the DNS-broken domains appear in historical Google Email transparency reports: tiviths.com.br tre-ce.jus.br tre-sp.jus.br tse.jus.br nsysu.edu.tw The associated DNS lookup issues are: _25._tcp.mailhost.bncr.fi.cr. IN TLSA ? ; ServFail _25._tcp.barracuda.nsysu.edu.tw. IN TLSA ? ; ServFail _25._tcp.lalavava.tse.jus.br. IN TLSA ? ; timeout _25._tcp.mx.tiviths.com.br. IN TLSA ? ; timeout _25._tcp.mandark.tse.jus.br. IN TLSA ? ; timeout _25._tcp.dexter.tse.jus.br. IN TLSA ? ; timeout [ See , Much of the TLSA non-response issue seems to be related to a "feature" of Arbor Networks firewalls, that enables droping of DNS requests for all but the most common RRtypes. Do not make the mistake of enabling this firewall "feature". ] The oldest outstanding DNS issue is another SOA signature issue at truman.edu dating back to Nov/2014: http://dnsviz.net/d/_25._tcp.barracuda.truman.edu/VGzORw/dnssec/ I hope some day soon they'll start missing email they care about and take the time to resolve the problem. -- Viktor.