From ietf-dane at dukhovni.org Fri May 1 08:27:05 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 1 May 2020 02:27:05 -0400 Subject: Update on stats 2020-04 Message-ID: <20200501062705.GW11496@straasha.imrryr.org> News: 1. The most significant development this month is from Google managed DNS. Since early April they appear to be signing all newly registered domains in a number of TLDs, including the top 3 most popular gTLDs: .com, .org and .net. This amounts to ~10k domains per day, and has led to significantly faster growth in the DNS domain counts for the affected TLDs. As a result the number of DNSSEC tracked by the DANE survey is now over 11.2 million. Some graphs showing the change: https://stats.dnssec-tools.org/tld-graphs/com.png https://stats.dnssec-tools.org/tld-graphs/org.png https://stats.dnssec-tools.org/tld-graphs/net.png https://stats.dnssec-tools.org/tld-graphs/info.png https://stats.dnssec-tools.org/tld-graphs/biz.png and perhaps most dramatically: https://stats.dnssec-tools.org/tld-graphs/page.png https://stats.dnssec-tools.org/tld-graphs/ca.png Congratulations and thanks to Google. 2. Also thanks to mijnhostingpartner.nl (a.k.a. mijnpartnergroep.nl) for resolving all outstanding DNSSEC denial of existence issues. Together with partial progress at registrar-servers.com the problem domain count is down ~50%. In short, much good news on the DNSSEC front this month. Summary: The DANE domain count is now 1,882,215 The number of domains that return DNSSEC-validated replies in response to MX queries is 11,181,237. Thus DANE TLSA is deployed on ~16.83% 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,882,215 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. 1028955 one.com 137999 transip.nl 100755 domeneshop.no 88978 loopia.se 74971 infomaniak.ch 38612 active24.com 31256 antagonist.nl 30954 vevida.com 28148 zxcs.nl 26886 web4u.cz 25101 udmedia.de 24999 webreus.nl 17442 bhosted.nl 15059 flexfilter.nl 13889 onebit.cz 10334 protonmail.ch 5791 netzone.ch 5632 soverin.net 5610 previder.nl 5435 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). 6520 TOTAL 2142 DE, Germany 1306 US, United States 955 NL, Netherlands 567 FR, France 267 GB, United Kingdom 226 CZ, Czechia 150 CA, Canada 89 SG, Singapore 89 CH, Switzerland 81 SE, Sweden 70 DK, Denmark 47 IE, Ireland 46 AU, Australia 45 AT, Austria 32 IN, India 31 BR, Brazil 28 RU, Russia 28 FI, Finland 27 PL, Poland 26 JP, Japan IPv6 is less common than IPv4 for MX hosts, and the top 20 countries by DANE MX host IPv6 GeoIP are: 3298 TOTAL 1366 DE, Germany 557 US, United States 490 NL, Netherlands 261 FR, France 115 CZ, Czechia 105 GB, United Kingdom 43 SE, Sweden 40 CA, Canada 39 CH, Switzerland 35 SG, Singapore 29 AT, Austria 22 RU, Russia 16 DK, Denmark 15 JP, Japan 15 ID, Indonesia 15 AU, Australia 13 NO, Norway 11 IE, Ireland 11 FI, Finland 11 BR, Brazil There are 5532 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 7682. These cover 8602 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 341 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 174 are in recent (last 90 days of) reports: 12gobiking.nl ingthink.com ru.nl ac-strasbourg.fr intermax.nl ruhr-uni-bochum.de active24.cz isc.org rvo.nl aegee.org itesco.cz samba.org asf.com.pt jpberlin.de schoudercom.nl atelkamera.nu kabelmail.de schuurman-schoenen.nl atlas.cz kadernickyservis.sk skatteverket.se bayern.de kingsquare.nl smtp.cz belastingdienst.nl klubpevnehozdravi.cz societe.com bhosted.nl kpn.com solvinity.com bluerail.nl krypton.cz ssonet.nl boekwinkeltjes.nl lazarus-ide.org star.dk boozyshop.nl leszexpertsfle.com stil.dk boplatssyd-automail.se litebit.eu t-2.com bund.de loopia.se t-2.net centrum.cz lrz.de telfort.com clubedominante.com lugeja.ee thalesgroup.com comcast.net mail.com theletter.se comeseetv.com mail.de tilburguniversity.edu compagnie-des-sens.fr mailbox.org torproject.org coosto.com mailplus.nl transip.net corpoflow.nl mailserver4.de trashmail.com cuni.cz mammoetmail.com triodos.be debian.org mensa.de triodos.co.uk dictu.nl minbzk.nl triodos.com digid.nl mindef.nl triodos.es dk-hostmaster.dk minmyndighetspost.se triodos.nl dns-oarc.net mkbbelangen.nl truetickets.nl domeneshop.no mm1.nl tu-chemnitz.de egmontpublishing.dk mpssec.net tum.de elster.de netbsd.org uib.no emta.ee netic.dk uitgeverijpica.nl ezorg.nl nic.br uni-c.dk fau.de one.com uni-erlangen.de fmc-na.com onebit.cz uni-muenchen.de freebsd.org open.ch unitybox.de freenet.de openssl.org unitymedia.de gentoo.org optimail.cz univie.ac.at gerryweber.nl orverkiezing.com utwente.nl gmx.at ouderportaal.nl uv.es gmx.ch overheid.nl uvt.nl gmx.com ozlabs.org virusfree.cz gmx.de pathe.nl volny.cz gmx.net personligalmanacka.se web.de goget.nu politie.nl web200.eu govtrack.us posteo.de web200.hu habr.com previder.nl webcruitermail.no habramail.net primexbt.com westlotto.de handelsbanken.no procurios.net whatpulse.org handelsbanken.se protonmail.ch xfinity.com hierinloggen.nl protonmail.com xfinityhomesecurity.com hostpoint.ch rediris.es xfinitymobile.com hotelsinduitsland.com registro.br xs4all.net hr-manager.net rijksoverheid.nl xs4all.nl ietf.org riseup.net xworks.net inexio.net rmit.ee zone.eu infomaniak.ch rotterdam.nl zonevs.eu infomaniak.com ru.ac.za zorgmail.nl Of the ~1.88 million domains, 4562 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 590. 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-how-to.md 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-records-with-le-certificates/7022/17 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 1128. The top 13 name server operators with problem domains are: 316 registrar-servers.com (significant reduction from last month) 72 movenext.nl 70 ebola.cz 69 axc.nl 43 cdmon.net 33 flevohost.nl 30 tiscomhosting.nl 28 hostnet.nl 22 infracom.nl 20 nrdns.nl 18 is.nl 16 metaregistrar.nl 14 eatserver.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 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 bncr.fi.cr ofda.gov[2] 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. [2] For ofda.gov, TLSA lookups return truncated answers over UDP when the EDNS buffer size is < 1555 bytes (e.g. to try and avoid UDP fragmentation). But the nameservers don't support TCP, so queries timeout unless the EDNS buffer size is sufficiently large. From dalias at libc.org Fri May 22 03:21:41 2020 From: dalias at libc.org (Rich Felker) Date: Thu, 21 May 2020 21:21:41 -0400 Subject: RFC7672 2.2.2 "Secure CNAME" considered harmful? Message-ID: <20200522012137.GA27724@brightrain.aerifal.cx> I've been reading RFC7672, in particular the part about TLSA lookup for the "Secure CNAME" case. Not only can I not find a legitimate reason to attempt to obtain a TLSA record for the fully-resolved CNAME first; further, I've come up with a very plausible scenario where it's actively harmful and allows an untrusted party to seize control of the service. Consider a service hosted on dynamic IP address. One way to do this without needing one's own dynamic DNS infrastructure is with CNAMES. If one owns example.com, one can make foo.example.com a CNAME pointing to a hostname on an existing dynamic DNS provider, e.g. example.dyn.com. Traditionally, prior to DNSSEC and DANE, this would have allowed dyn.com to hijack the service by redirecting the A record for example.dyn.com. However, if example.com is authenticated by DNSSEC and has a TLSA record pinning a particular key for foo.example.com, one would expect this hijacking no longer to be possible -- if dyn.com redirected example.dyn.com, they would not have the private key matching the TLSA record, and could not hijack any traffic from clients performing DANE validation. However, RFC7672 section 2.2.2 specifically overrides this expectation for SMTP, and mandates that, if dyn.com is also authenticated, clients attempt to obtain a TLSA record for example.dyn.com and give it precedence over the one for foo.example.com. This reopens the possibility of hijacking, and seems outright wrong. I believe it can be mitigated by someone aware of the problem, with a dummy intermediate insecure zone: foo.example.com CNAME foo.dummy-insecure.example.com foo.dummy-insecure.example.com CNAME example.dyn.com where dummy-insecure.example.com is a zone that's intentionally left unsigned, to break the chain of authenticated data. But it seems unrealistic to expect people to know to do this, and error-prone since subtly non-conforming clients may misinterpret the broken chain of authenticated data as foo.example.com being insecure and not subject to DANE at all. Can anything be done about this? Is there a reason for the existence of the "Secure CNAME" case that needs to be preserved, or is this something that could be pushed for deprecation? From ietf-dane at dukhovni.org Fri May 22 05:09:39 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 21 May 2020 23:09:39 -0400 Subject: RFC7672 2.2.2 "Secure CNAME" considered harmful? In-Reply-To: <20200522012137.GA27724@brightrain.aerifal.cx> References: <20200522012137.GA27724@brightrain.aerifal.cx> Message-ID: <20200522030939.GX68966@straasha.imrryr.org> On Thu, May 21, 2020 at 09:21:41PM -0400, Rich Felker wrote: > I've been reading RFC7672, in particular the part about TLSA lookup > for the "Secure CNAME" case. Not only can I not find a legitimate > reason to attempt to obtain a TLSA record for the fully-resolved CNAME > first; further, I've come up with a very plausible scenario where it's > actively harmful and allows an untrusted party to seize control of the > service. This is not the right forum for this topic. Likely dane at ietf.org may have been more appropriate. 1. In fact MX records are supposed to not be CNAMEs. So you should not, and generally would not operate the inbound MTA for a domain via a CNAME to dyn.com. 2. Despite the above, most MTAs do honour "CNAME-valued" MX records. And the majority of those cases, the CNAME points at an MX provider, not a DNS-resolution provider like dyn. 3. If your IP records CNAME into a zone managed by an untrusted party, they can make your A-records appear unsigned, and some implementations will not fall back to a CNAME query to check for DNSSEC in the MX host's zone. The fallback CNAME check is tricky, and I do not expect it to be consistently. 4. In most such cases, the CNAMEs in question are multiple names for the same MTA managed by its owner, or aliases to a provider managed mailserver. Not a mailserver for which just the IP record is outsourced to a third party. In the actual cases in use, the users benefit from a single operator managing both the target IPs and the target TLSA records. They would otherwise have to be sure to publish additional CNAMEs from their TLSA qname to the provider's TLSA RRset. This is extra work they're likely to neglect. For example 472 domains alias MX hosts to mail.kingsquare.nl. Bottom-line, my take is you're grasping at straws. > I believe it can be mitigated by someone aware of the problem, with a > dummy intermediate insecure zone: > > foo.example.com CNAME foo.dummy-insecure.example.com > foo.dummy-insecure.example.com CNAME example.dyn.com > > where dummy-insecure.example.com is a zone that's intentionally left > unsigned, to break the chain of authenticated data. Yes, though as I mentioned, this can also break DANE, and nobody is going to do this... > But it seems unrealistic to expect people to know to do this, We're on the same page here. > Can anything be done about this? Is there a reason for the existence > of the "Secure CNAME" case that needs to be preserved, or is this > something that could be pushed for deprecation? Wrong forum, and we disagree. -- Viktor. From dalias at libc.org Fri May 22 05:31:32 2020 From: dalias at libc.org (Rich Felker) Date: Thu, 21 May 2020 23:31:32 -0400 Subject: RFC7672 2.2.2 "Secure CNAME" considered harmful? In-Reply-To: <20200522030939.GX68966@straasha.imrryr.org> References: <20200522012137.GA27724@brightrain.aerifal.cx> <20200522030939.GX68966@straasha.imrryr.org> Message-ID: <20200522033132.GQ1079@brightrain.aerifal.cx> On Thu, May 21, 2020 at 11:09:39PM -0400, Viktor Dukhovni wrote: > On Thu, May 21, 2020 at 09:21:41PM -0400, Rich Felker wrote: > > > I've been reading RFC7672, in particular the part about TLSA lookup > > for the "Secure CNAME" case. Not only can I not find a legitimate > > reason to attempt to obtain a TLSA record for the fully-resolved CNAME > > first; further, I've come up with a very plausible scenario where it's > > actively harmful and allows an untrusted party to seize control of the > > service. > > This is not the right forum for this topic. Likely dane at ietf.org may > have been more appropriate. > > 1. In fact MX records are supposed to not be CNAMEs. So you should > not, and generally would not operate the inbound MTA for a domain > via a CNAME to dyn.com. > > 2. Despite the above, most MTAs do honour "CNAME-valued" MX > records. And the majority of those cases, the CNAME points > at an MX provider, not a DNS-resolution provider like dyn. > > 3. If your IP records CNAME into a zone managed by an untrusted > party, they can make your A-records appear unsigned, and some > implementations will not fall back to a CNAME query to check > for DNSSEC in the MX host's zone. The fallback CNAME check > is tricky, and I do not expect it to be consistently. Indeed, that's a really good point. This flakiness of client implementation probably makes such a setup a non-starter. > 4. In most such cases, the CNAMEs in question are multiple > names for the same MTA managed by its owner, or aliases to > a provider managed mailserver. Not a mailserver for which > just the IP record is outsourced to a third party. > > In the actual cases in use, the users benefit from a single operator > managing both the target IPs and the target TLSA records. They > would otherwise have to be sure to publish additional CNAMEs from > their TLSA qname to the provider's TLSA RRset. This is extra work > they're likely to neglect. > > For example 472 domains alias MX hosts to mail.kingsquare.nl. This would still work with the opposite priority order: TLSA for the domain named in the MX taking precedence, with fallback to TLSA for the fully-resolved CNAME if there is no TLSA record for the former and the full CNAME chain is authenticated. > Bottom-line, my take is you're grasping at straws. I don't see how that's an apt description of a question about a possible flaw in the security design. > > Can anything be done about this? Is there a reason for the existence > > of the "Secure CNAME" case that needs to be preserved, or is this > > something that could be pushed for deprecation? > > Wrong forum, and we disagree. Can you point me to a description of what is on-topic here? Even if this is not the right forum to make change, it seems like a reasonable forum to gauge opinion on the topic from people actually using DANE with SMTP and determine if or how approaching it in another forum (IETF) might be appropriate. Rich From ietf-dane at dukhovni.org Fri May 22 07:16:40 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 22 May 2020 01:16:40 -0400 Subject: RFC7672 2.2.2 "Secure CNAME" considered harmful? In-Reply-To: <20200522033132.GQ1079@brightrain.aerifal.cx> References: <20200522012137.GA27724@brightrain.aerifal.cx> <20200522030939.GX68966@straasha.imrryr.org> <20200522033132.GQ1079@brightrain.aerifal.cx> Message-ID: <20200522051640.GY68966@straasha.imrryr.org> On Thu, May 21, 2020 at 11:31:32PM -0400, Rich Felker wrote: > > For example 472 domains alias MX hosts to mail.kingsquare.nl. > > This would still work with the opposite priority order: TLSA for the > domain named in the MX taking precedence, with fallback to TLSA for > the fully-resolved CNAME if there is no TLSA record for the former and > the full CNAME chain is authenticated. That could have been a possibility, as indeed would requiring the domain owner to actively provision a CNAME from _25._tcp. to _25._tcp.. I optimized for two considerations: 1. Ease of deployment. If your MX host provider (possibly after CNAME resolution) has TLSA records, you're done. 2. Alignment of operational responsibility. Whoever is operating the MX host is best positioned to keep correct TLSA RRs in place. This meant preferring the TLSA RRs as close as possible to the actual MX host domain. Now you have a corner case where the MX host is really in the origin domain, and only its IP address resolution is delegated. I must admit this was not considered at the time, but that I am considering it, I am not especially fond of the idea of switching the order of precedence. What I can say is that TLSA RRs after CNAME indirection are not terribly common, and we could (at the cost of not supporting DANE for a small fraction of users) drop the CNAME chasing, not because of the dyn.com situation, but simply because it is complex, and perhaps not worth the cost. > Can you point me to a description of what is on-topic here? Even if > this is not the right forum to make change, it seems like a reasonable > forum to gauge opinion on the topic from people actually using DANE > with SMTP and determine if or how approaching it in another forum > (IETF) might be appropriate. This is a very quiet list, mostly just my monthly posts, but occasionally some operational topics. Not much standards discussion here. It'd probably be just you and me, and we could do that off-list. I could be misjuding who's here of course... -- Viktor.