ietf-dane

Trends in eTLD+1 zone (effective TLD + 1, e.g. example.com, example.co.uk, ...) DNSSEC algorithm adoption. The graph plots the number of delegated domains with a given DNSKEY algorithm in the corresponding DS RRset published in the parent (eTLD) zone.

<https://dnssec-stats.ant.isi.edu/~viktor/algs-ds.png>

Someone not well informed on the matter was rumoured to say that DNSSEC does not work well with ECDSA P-256. This is far from the case. New implementations are increasingly ECDSA, and further bulk rollovers will happen. Many resolvers are not yet ready for EdDSA 25519 or Ed448, so those will not happen in bulk in the short term. Need a few more LTS OS releases that lack Ed25519 support to be phased out before that happens.

It has been said about fundamental science that progress happens one funeral at a time... Something like that is applicable to core infrastructure, it is rarely upgraded, more typically replaced. So the lifecycles are somewhat longer.

In fact ECDSHAP256SHA256(13) will shortly be the most prevalent DNSSEC algorithm, and already has been a few times but for recent algorithm rollovers from the deprecated RSASHA1(7) (90% down from peak and falling) to RSASHA256(8) that temporarily put RSA(8) back in front.

The supremacy of RSA(8) over EC(13) is not for long: <https://stats.dnssec-tools.org/images/ksk-algs.png>. A month ago there was a 1.2M zone gap, it is now down to ~150k, and will soon be gone.

The TLDs have been a bit slower to adopt P256, just 45 so far, but these include e.g. .cz, .br, .ch and .fr. There will be more TLDs switching to ECDSA in 2022.

One thing that needs to be stressed is the importance of monitoring your deployment [unmonitored security should be an oxymoron].

The author's diligence is impressive, and I am sure he learned a lot doing it (kudos), but of course for most users DYI toolchains are not the most cost-effective investment of resources. Just go with e.g. BIND 9.16 which has quite decent built-in key management.

I've noticed, but this is well known, and it has perhaps been a while since you've said anything substantively new about them. Your views are well known, and easily found via any search engine. There's likely no compelling need to track down and attempt to refute each positive mention. This thread excepted, I've generally not engaged in the converse.

I am looking for a truce, where we each get to post whatever new thing we have to report, without having to expend precious energy to deal with redundant rebuttals. If you like, I can append "[naturally tptacek disgrees]" whenever I report anything DANE related to this forum, and save you the trouble... :-)

Looking beyond just .com at three more TLDs, one day later Google signed:

  * 4740 .com
  *  925 .page
  *  662 .org
  *  413 .net

For a total of 6740 new DNSSEC domains. This ongoing activity is reflected in a noticeable recent uptick in the growth rates of DNSSEC for these TLDs:

  https://stats.dnssec-tools.org/tld-graphs/com.png
  https://stats.dnssec-tools.org/tld-graphs/page.png
  https://stats.dnssec-tools.org/tld-graphs/org.png
  https://stats.dnssec-tools.org/tld-graphs/net.png

That's done and dusted, what's happening now for example is that today 7620 new .com domains got signed, ~73% of them by googledomains.com. And roughly the same thing is happening every day:

https://stats.dnssec-tools.org/tld-graphs/com.png

Sure, if the pace stays the same it works out to about 2 million per year, which is cool, but there are over 140 million .com domains, so more than just Google would need to engage in large-scale signing.

I am not denying that until recently things have been slow to moribund, but things have started to change, and where we part ways is that you've written off all possibility of change based on past stasis, but I'm ignoring it and having some real, if early, success at driving change.

My take is that you're under no obligation to contribute or even admit that change is starting to happen, but I think it would be polite to back off on the negativity, just wait and see, you may be proved right without expending any energy being vocal about it. But if adoption picks up unexpectedly, allow yourself to be surprised...

Cloudflare does not MX-host customer domains, so is not in scope, they DNS-host signed domains, but that's not what the above is about. Google also DNS-hosts many signed domains (under the cloud.goog, .dev and .app TLDs).

I was listing DANE adoption since 2015, which is really when the clock starts, the signing of the root zone in 2010 was just a prerequisite, but not enough by itself. The DNSSEC use-case in question is DANE for SMTP, which was not possible earlier.

The Heartbeat example is absurd. DANE support is in MTAs that actually use it, and not just some landmine in an open-source library. Some of the larger providers use commercial SMTP stacks that support DANE, others use open-source, but any analogy with Heartbeat other than it was also open-source is much too weak to warrant consideration.

The timescales that matter are:

  2010 - Root zone signed
  2012 - Base DANE specification
  2013 - First DANE SMTP draft, Snowden
  2015 - SMTP DANE TLS RFC
  2015 - DANE live at udmedia.de, mailbox.org, posteo.de, xs4all.nl, comcast.net, debian.org, freebsd.org, ...
  2016 - DANE live at web.de, gmx.de, transip.nl, domeneshop.no, ...
  2018 - one.com, ...

Along the way, support for DANE in SMTP for Postfix, Exim, Halon, PowerMTA, MailChannels, ... Also OpenSSL and GnuTLS and now 1.88 million domains with DANE MX hosts. It has taken me seven years to get real momentum behind DANE for SMTP, and will likely take another seven to see how it plays out...

You may not have the patience, but I am prepared to play the tortoise racing the sleeping hare.

Well, there's also a significant rate of adoption in Brazil. US domains await support from Godaddy et. al., with Godaddy recently announcing that DNSSEC will be available as a standard offering, not just a premium option. Adoption barriers still exist, but are falling.

I am not expecting miracles overnight, but I'm patiently playing the long game, and not too worried about the past or the status quo.

Yes, precisely, they and many, many others. The Internet I want to nurture is the decentralized Internet that links millions of independent actors, rather than the walled-garden Internet of 3 cloud platforms. I am of course pleased to see also the big players supporting open technologies.

Here's a longer list of providers MX-hosting over 1k domains for customers with DNSSEC and DANE:

  1033606 one.com
   136407 transip.nl
   100893 domeneshop.no
    88794 loopia.se
    72402 infomaniak.ch
    38424 active24.com
    30972 vevida.com
    30549 antagonist.nl
    27595 webreus.nl
    26928 web4u.cz
    26122 zxcs.nl
    25001 udmedia.de
    17389 bhosted.nl
    15135 flexfilter.nl
    13863 onebit.cz
     9925 protonmail.ch
     5798 netzone.ch
     5597 previder.nl
     5461 soverin.net
     5058 zonemx.eu
     4803 mailplatform.eu
     3406 ips.nl
     3072 interconnect.nl
     2568 provalue.nl
     2084 nederhost.nl
     1932 spamcluster.nl
     1836 mailbox.org
     1673 nmugroup.com
     1445 yourdomainprovider.net
     1348 mijnspamfilter.nl
     1326 hi7.de
     1297 tutanota.de
     1255 spamfilterserver.com
     1219 surfmailfilter.nl
     1151 prolocation.net
     1009 xcellerate.nl

It is more difficult to measure the scale of deployments by individual domains with large numbers of users, as the numbers are not apparent in DNS, but these include comcast.net, web.de, gmx.de, ...

The inertia to overcome is enormous, and the deployment time scale will be comparable to IPv6, which is just starting to gain ground after 3 decades. No need to tighten your seatbelt, it's a long ride, but adoption is growing and even accelerating. It would be nice and not too surprising, to get from the current ~2.5% (11 million signed domains out of ~400 million overall) to >5% in the next few years.

A few recent DANE deployments:

  * infomaniak.ch - Swiss hosting provider
  * triodos.com - Bank in Spain
  * startupstack.tech - California hosting company
  * elbiahosting.sk - Slovak hosting company
  * isu.net.sa - Saudi research centre
  * statens-it.dk - Multiple Denmark government domains
  * startmail․com - Email provider in Germany
  * webreus.nl - hosting provider in the Netherlands
  * mailfence.com - Email provider in Belgium
  * velocir.co.uk - UK hosting and email provider

In the last 90 days 108k new domains via 828 new providers, plus more domains via existing providers, now 1.88 million domains total.

Microsoft has a titanic-sized infrastructure to turn around, so it won't happen overnight, but they and more will deploy as time marches on, and in the mean-time it is MTA-STS that's moribund...

DNSSEC deployment is growing steadily:

  https://stats.dnssec-tools.org/images/totalds.svg
  https://stats.dnssec-tools.org/tld-graphs/com.png
  https://stats.dnssec-tools.org/tld-graphs/net.png
  https://stats.dnssec-tools.org/tld-graphs/org.png
  https://stats.dnssec-tools.org/tld-graphs/biz.png
  https://stats.dnssec-tools.org/tld-graphs/info.png
  https://stats.dnssec-tools.org/tld-graphs/us.png

The USA is #2 behind Germany by number of DANE-enabled MX host IPs:

  https://mail.sys4.de/pipermail/dane-users/2020-April/000553.html

The USA is not always the best practice to emulate. Microsoft's SMTP servers host mail for at least 284k (today's count) signed domains. When they enable inbound DANE, these (likely more by then) will be protected by DNSSEC and DANE.

The rear-view mirror is not always the best guide to the road ahead.

Progress is tracked at: https://stats.dnssec-tools.org/#dnssec

Where "larger" really means Google and Yahoo, others as you now see are less zealous about MTA-STS as the main way forward (there's little sign of broad adoption beyond a small number of the largest providers).

For Google, part of the issue is that signing "google.com" where the MX hosts live is a non-trivial endeavour given all the DNS-based load-balancing kit that's deployed at scale. That can be solved by e.g. switching the MX hosts to another domain, e.g. "smtp.goog" which is signed, and already has mx[1-4].smtp.goog as alternative MX hosts for the same domains (gmail.com and all the G-suite hosted ones). All that's required is TLSA RRs for these, and presto-magic, inbound DANE for Google-hosted domains that are signed and have designated these MX hosts (some already have, despite lack of official guidance from Google that these are supported, nagging for such guidance continues...).

And of course gmail.com could be signed without having to sign google.com, so given willpower to get it done, technically they have a simple way forward.

For yahoo.com, there's no separation between the email domain and the (does anybody still care about it) website. So DANE SMTP for yahoo.com could be more difficult, but again not insurmountable, if they still have any resources left to get new things done. If they're only on life-support, then probably not any time soon. (I'm still waiting for native IPv6 from Verizon Fios...)

Another significant obstacle is perhaps internal politics. There is sadly some quasi-religious zeal (feels like in-group vs. out-group territoriality) around "dislike" of DNSSEC. True believers in the faith are wiser and more prescient than us unenlightened masses, and have been effective barriers to progress in more than one organization.

There's of course work to be done to improve DNSSEC usability (with significant progress in e.g. BIND 9.16 automating key rollover, not just resigning), especially the interface between registrant and registrar, where CDNSKEY/CDS support would remove barriers to KSK management.

It would be great to see more domains upgrade from RSA-2048 KSK + RSA-1024 ZSK to ECDSA P-256, or at least at a 1280-bit RSA ZSK, with adequately frequent (~90 day or so) ZSK rollover. For RSA, algorithms 5 and 7 which use SHA-1 signing (now deprecated) need to be upgraded to 8 or 10 which use SHA2.

Internet-scale infrastructure changes take effort and time, and if you're not actively participating, at least try to not get in the way.

Let's compare notes in 2020 or 2021. Infrastructure upgrades happen slowly... I'll stop now and we'll both find something actually productive to do.

Yawn, would you also like to arm wrestle? I concede that smug superiority gets more karma points than doing the hard work to make a difference.

Yes, only ~9 to 10 million domains are presently signed, and most of the larger ones are not (but comcast.net and cloudflare.com are not tiny, and gmx.de has over 10 million email users). Changing this takes time and effort. Users still need better software tools that make deployment easier and there needs to be less KSK deployment and rollover friction at the registrars and registries (i.e. CDS support). Some DNS hosting providers with outdated software need to upgrade their stacks, ... this does not happen overnight. Let's compare notes in 2020 or 2021. Infrastructure upgrades happen slowly...

Yes, DANE works for SMTP. Let's talk again in 2020. Ciao...

gmx.de, comcast.net, freenet.de, mailbox.org, posteo.de and tutanota.de come to mind as counter-examples as well as various universities, the German parliament, various Dutch government domains, and a couple of thousand self-hosted SOHO domains. But DNSSEC is axiomatically evil, so I must be wrong...

[ For the record, not an invitation to a futile further debate, given your long-standing immutably-held views on DNSSEC. Since you'll probably say the same about my work to get DANE for SMTP up and running, we can stop here. All I can add is that those who say it can't be done should not get in the way of the people doing it... :-) ]

No, the major providers did not get together to do MTA-STS because DANE was bad. They did it because their existing DNS geo-balancing kit for e.g. google.com and yahoo.com does not offer an easy upgrade path to DNSSEC. Note that Microsoft has a dedicated domain (outlook.com) for email hosting, and can more easily do DNSSEC there without impacting their other "web properties". Note also that Google now MX-hosts many customer domains on "googlemail.com" rather than google.com.

So things are starting to change. Furthermore, there are now over 1 million DANE-enabled DNSSEC domains. MTA-STS is far behind, is not downgrade-resistant on first contact and uses weak CA-leap-of-faith DV authentication. It will probably be enabled at the biggest providers by the end of this year, but as you yourself said elsewhere, these providers are the threat, and if so, securing email delivery to the user surveillance empires is not necessarily that important. Mind you, they can play a useful role by enabling validation and helping to keep the TLSA records of receiving systems valid, and perhaps surveillance is not their business for paying customers...

Crypto maximalists don't like additive security mechanisms that reduce the risk and potential scope of attacks, but may not address every possible attack vector. Often the effect of crypto maximalism is reduced security. In the real world it takes multiple mitigating technologies to address a problem, and perfection is not always achievable. See RFC7435.

Other big problems with WebPKI:

* DV certificate issuance is based on a leap of faith (TOFU) by the CA. It is vulnerable to BGP hijack, DNS cache poisoning, ... as amply illustrated by the "domain control" "proofs" in ACME.

* The CA ecosystem is dying with Let's Encrypt's free certs removing the raison d'etre for most of the other CAs. Actual verification of identity does not scale, and DV "domain control" "verification" does not pay.

Crypto:

* The use of SHA1 in DNSSEC is not subject to collision attacks, only 2nd pre-image resistance is required, and there's no hint of SHA1 (or even MD5!) 2nd pre-images any time soon. While moving to SHA256 makes sense, there's no real problem with SHA1 in DNSSEC, it is adequately secure.

* The domains using 512-bit keys are a tiny minority hosted by a couple of DNS hosting providers (one of them "free", so you get what you pay for).

* Most zones have 2048-bit KSKs, and 1024-bit ZSKs. This can be addressed as more domains deploy ECDSA or 1280-bit and 1536-bit RSA keys (which have an estimated work-factor of 89 and 96 bits respectively, and there is ). The root zone keys are 2048 bits for both KSK and ZSK, and 1 in 3 TLDs has 1280-bit ZSKs, more will do that or switch to EC.

* Logjam researchers estimated the cost for a single widely used DH key (embedded as a constant in software): "The researchers calculated the cost of creating logjam precomputation for one 1024-bit prime at hundreds of millions of USD". This is somewhat specific to DH rather than RSA, and leverages the fact that many users used the same fixed DH groups. ZSKs are not fixed and vary across providers.

* Many estimates of RSA factoring cost ignore memory costs, for a more realistic analysis, see https://pdfs.semanticscholar.org/5f56/b7e3d8423cffa724d8037e...

Finally: the talk is about improving on unauthenticated opportunistic TLS in SMTP. The right comparison is with downgrades to cleartext, not with the latest fashionable crypto in browsers. The browsers moving from 1024-bit RSA directly to 2048-bit RSA is a bit of power-of-two numerology and was overkill (better optics more than better engineering). They did it because signing and verification are still adequately fast, so they can get away with turning it up to 11. That does not mean that more modest key sizes are not effective. Since DNSSEC is used only to authentication, not key agreement, there's no risk from future key compromise once a key is retired, so keys don't need to remain secure for decades, just a few months (for a ZSK) is enough.

Generally, real-world attacks bypass the crypto and attack far weaker defenses. Why break the crypto when you can subpoena the private key material, install malware on the end-systems, break TOFU certificate issuance...

Smug attacks on DNSSEC ignore many deficiencies of the alternatives, and are I suggest a case of letting the perfect be the enemy of the good.

The 512-bit RSA keys are a distraction. You're allowed to not care about the security of your own domain, but if your DNS hosting provider does not, and you do, get a better DNS hosting provider, all but two (of any size) use stronger keys.

ECDSA P-256 and P-384 are widely deployed. New algorithms will take some time to be widely supported by peer resolvers, just as TLS 1.3 will take time to be widely supported by web sites (browsers are more agile, but many websites still don't do forward-secrecy with TLS 1.2).

Algorithm agility is a thorny problem.

Why is SMTP not like the web: https://tools.ietf.org/html/rfc7672#section-1.3

Survey says: 5.2 million DNSSEC domains, and ~12,000 with 512-bit RSA keys concentrated at just two small DNS providers. So good job knowing only the few stuck with early 90's export crypto. :-) They'll be shamed into fixing this soon enough. An even larger provider that had 512-bit RSA keys no longer does.

And even a 512-bit RSA key is slightly better than nothing. One needs to remember that DANE in SMTP is a mechanism for downgrade-resistant transition from unauthenticated opportunistic STARTTLS to authenticated required STARTTLS.

Below is the frequency table for RSA key lengths in zone signing keys (primarily 1024-bit RSA keys):

  count  | bits
 

---------+------

    8402 | 4096

    1135 | 3168

      17 | 2432

     103 | 2304

      20 | 2088

       5 | 2064

   55927 | 2048

      15 | 2024

     315 | 1536

      17 | 1352

      43 | 1304

  185095 | 1280

      63 | 1152

      74 | 1048

     291 | 1032

 4019966 | 1024

      28 |  768

   12545 |  512

The KSK (key-signing keys registered in parent DS RRs) RSA key size frequencies are (mostly and increasingly 2048-bit):

  count  | bits
 

---------+------

   39715 | 4096

      11 | 3248

    1149 | 3168

      47 | 3072

     267 | 2560

      25 | 2304

      20 | 2088

 3051386 | 2048

      17 | 1552

  180111 | 1536

     171 | 1304

    1568 | 1280

      34 | 1152

 1118500 | 1024

   11806 |  512