This is truly momentous. This should be on the HN front page.
This will help get Google and others to follow suit.
With all the big players using DNSSEC and DANE, you can expect close to universal deployment, and that will be a game changer for Internet security.
None of this would have happened without Viktor Dukhovni's incredible effort these past several years. He built a survey of DANE usage so as to find brokenness and get it fixed -- long-term brokenness would have caused the protocol to get abandoned. Once the big players have DANE support, them and everyone else will have huge incentive to monitor their own domains for breakage, which will make breakage a rarity.
It's been 25 years and deployment is stuck at 1%, with virtually none of the major tech companies --- Microsoft included, since none of their zones are signed --- in that set.
Microsoft cosponsored MTA-STS, the competing solution that doesn't use DNSSEC.
I think you're right: Microsoft is doing this because European customers are demanding it. DNSSEC is moribund. It may be a quirky thing that companies in Europe do, but it isn't going anywhere elsewhere.
* 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...
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:
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.
See, you go into this thinking maybe "elbiahosting.sk" is a fluke, but no, "flexfilter.nl" and "tkservers.com" (whose home page redirects straight to a Roundcube login) are right there with them. Mailplatform.eu is DNSSEC-signed? Can Google Mail be far behind?
Essentially, you're going to be able to demonstrate that DNSSEC is widespread in Europe. I concede that readily. I absolutely believe DNSSEC has a long future as an idiosyncratic thing only European companies do.
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.
When it's like, a couple months, or even a year or so, sure, the past might not have much to tell you. But it's been twenty -five years. Even if you start at DNSSECbis, it's been almost 20 years since the typecode roll. At some point, ignoring the past stops being such a prudent strategy.
I mean, x.509 is even older, and yet we still don't have a real PKI.
There's no reason to think that some technology being 25 years old means it's dead if not used already.
We have to realistic paths to a true PKI, both based on DNS: a) DNSSEC, b) the registries/registrars operate name-constrained (as least as anchors) CAs. That's it.
The WebPKI offers little real security. Certificate transparency is just like DNSSEC -- it needs big deployment to be a win, and it's especially needed because we don't trust the CAs because there's so many because they are not name constrained.
In DNSSEC the trust problem is still there, so CT could be applied to DNSSEC, but if you use QName minimization then it's harder for the root zone and TLDs to decide when to MITM you -- that's a really strong characteristic that PKIX couldn't hope to have because it doesn't have a directory. (Stapling DNSSEC chains in TLS would defeat this, but it is needed for last mile reasons, such as hotel networks.)
Nobody likes the WebPKI. But if you posted the private key for any trusted CA on Pastebin, it would be a very big deal. People around the world would get paged, and many of them would actually have to come in to work.
Contrast that with DNSSEC. The root key for the entire Internet, the one they have the secret Stonecutters ceremony to establish, could end up on Pastebin tomorrow and nothing would happen. Nothing would happen the next day either. Weeks could elapse and nothing would happen.
What's more, the comparison holds if you go back a year, 2 years, 10 years. The WebPKI is old (though evolving, unlike DNSSEC, for which things like transparency logs remain defensively evoked hypotheticals), but it has been important throughout it's life.
Hell, the application of DNSSEC we're talking about here is subsidiary to the WebPKI --- it's simply making sure that mail servers speak WebPKI-secured TLS to each other!
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.
Even by the artificial timeline you provide, it's been 10 years since DNSSEC was rolled out in its current form in the root zone. That list of domains you've provided is almost the best you can do (you forgot Cloudflare).
Open source software support for DANE doesn't mean anything. Open source software supported the TLS Heartbeat Extension, too.
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 point is simply that implementation in open source projects doesn't imply user (or even operator) adoption. It's not really a metric of anything. People want to build features like these; it's fun.
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:
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...
I'm overtly and deliberately negative about DNSSEC and DANE. I think they're bad protocols, and bad for the Internet. It would be impolite for me to pretend otherwise.
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... :-)
I try not to write off topic rebuttals. If you perceive something I write about DNSSEC to be off topic --- for instance, if someone posts that, I don't know, netqmail suddenly supports DANE, and I materialize saying "DANE is dumb", I will accept and concede the criticism that that's unproductive.
If, on the other hand, you post "Microsoft has announced it will stop actively impeding people from using DANE for email, this is a momentous step forward for the deployment of DNSSEC", I will probably explain why I strongly believe that not to be the case, and not feel too bad about it.
I respect that you disagree and, while I do sometimes resort to overt snark, hope not to personally offend you or anyone else, or, for that matter, to crud up threads so that it's impossible to discuss things without an airing of my own issue agenda.
So, while I'm not sure I can honestly offer a "truce", I will try to be more mindful about not disrupting DNSSEC discussions too much.
OK, I looked. Here's my response. Call it "Against Against DNSSEC, and For DNSSEC".
> DNSSEC is Unnecessary
Quite the contrary. If nothing else, it's the only technology we have with proof of non-existence. That's very valuable.
> DNSSEC is a Government-Controlled PKI
If you use QName minimization then it's really hard for the government to abuse those keys: they'll get caught unless they MITM you all the time, and to do that they need to know exactly who to MITM all the time. It was always important to use QName minimization anyways -- essential, I'd say.
Also, anyone can run their own roots, and you can bet that other governments (e.g., Russia's) have plans to run their own if need be.
WebPKI is no-PKI. Whether it's WebPKI or real-PKI, CAs can be subverted by the governments that have jurisdictions over them. CT is not yet clearly a good enough answer (it's post-hoc, for one), but if it is then guess what: CT would also work for DNSSEC.
I.e., everything is "government-controlled", and no technology beats the rubber hose. Thus "DNSSEC is government-controlled PKI" is grossly misinformed in the best case, or willful FUD in the worst case.
> Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
As if the U.S. could not get ICANN to change the .ly delegation if it came to it.
> DNSSEC is Cryptographically Weak
DNSSEC supports new algorithms.
> No cryptosystem created in 2015 would share DNSSEC’s design.
WebPKI has the same problems because... PKI has this problem... because many protocols have this problem, that you have to support old algorithms for a while. TLS has this problem too.
BTW, PKCS#1.5 is especially bad for encryption, but not so much for signatures. See https://cryptosense.com/blog/why-pkcs1v1-5-signature-should-... which argues that PKCS#1.5 should be replaced for signatures, but clearly the situation for signatures is infinitely less bad than for encryption.
> DNSSEC is Expensive To Adopt
> [DNSSEC] adds two new failure cases: the requestor could be (but probably isn’t) under attack, or everything is fine with the name except that its configuration has expired.
TLS (WebPKI) has that too. Also, just because a zone is signed doesn't mean that an application making queries against it needs to validate signatures -- you can have DNS-using apps that are DNSSEC-oblivious. DNSSEC doesn't make using DNS worse in apps where validating DNSSEC signatures is not useful. DNSSEC enables new / improved applications however.
And... DANE for SMTP adoption, and Viktor's yeoman's work on that are making it less expensive to adopt and run DNSSEC by causing more effort to be put into making it effortless.
By poo-pooing DNSSEC you might cause some people to shy away and thus you are part of the reason DNSSEC is hard to adopt.
> A lot of code will need to be rewritten to make DNSSEC workable.
No, a lot of code will need to be modified to take advantage of DNSSEC. That's a huge difference.
Yes, browsers don't bother with DNSSEC. That's fine. Eventually they might (I predict will).
> DNSSEC is Expensive To Deploy
See above.
> DNSSEC is Unsafe
> ...
> But DNSSEC is designed for offline signers; it doesn’t encrypt on the fly.
First off, you meant sign, not encrypt. Secondly, that's flat out wrong. A number of large providers sign records on the fly. PowerDNS supports it. It's not hard. In fact, it's easier than offline signing.
This section is so wrong I don't know where to start. You essentially imply that end-to-end security shouldn't rely on trusted third-parties:
> A casual look at the last 20 years of security history backs this up: effective security is almost invariably application-level and receives no real support from the network itself.
Oh? So no WebPKI either then. No DNS for that matter. Or routers. Just IP-over-pigeons, I guess. (I can snark too. It's not very nice though. I'm starting to snark because the "Against DNSSEC" arguments are so trivially bad.)
Finally we come to the crux:
> DNSSEC doesn’t have to happen. Don’t support it.
All I see is that you don't want it to happen, so you take advantage of your abrasive personality and sheepish people to spread ill-founded, snarky FUD against it.
You don't even address the arguments for DNSSEC. You just attack [with dull blades]. One would think that addressing the arguments for DNSSEC would be part of the argument against it -- it would be the polite and professional thing to do. I'm prepared for DNSSEC not to be the answer, but I'm not prepared to accept your say-so on the basis of "Against DNSSEC".
It's funny though, you don't make the one argument against DNSSEC that for a long time has been most well-founded: the DDoS threat from response magnification. Fortunately the Internet is moving to DoH and DoT, which means using TCP, which means making the DDoS problem go away. Also DNS cookies are getting more support. Also, modern pre-post-quantum signature algorithms have smaller signatures anyways, which further makes DNSSEC less useful for DDoS.
I'm not saying there's no DDoS issue, just that it's getting mitigated or fixed, and it's not even an argument you made in Against DNSSEC.
In conclusion: "Against DNSSEC" is wrong and weak tea.
"For DNSSEC" certainly needs to be stated though. I don't want to just tear down your article. Briefly:
- DNSSEC is the *only* properly name-
constrained PKI we have;
- DNSSEC does provide usable security
against misbehaved zones (CAs) when
resolvers apply QName minimization
(see above);
- CT could be applied to DNSSEC if QName
minimization were insufficient;
- no certificate tax (fortunately Let's
Encrypt has made that less of an
issue anyways, but still, see points
about name constraints);
- DNSSEC enables DANE;
- DANE enables better and somewhat more
optimized authentication because of a)
happening in DNS, b) having authenticated
denial of existence.
Note that we could build a different properly name-constrained PKI out of DNS but without DNSSEC: just make all the registries/registrars CAs and have their trust anchors be name-constrained even if the certificates they issue still can't be name-constrained for whatever reason. This would be good, really good, if we have to stick to PKIX (which I don't mind), but it wouldn't be as good as DNSSEC due to the lack of authenticated denial of existence. Note that you'd still need to use QName minimization because you probably would (correctly) worry about government (and other) subversion of CAs, and you should want to use QName minimization to make it harder for any would-be MITM to decide when to get in the middle.
This will help get Google and others to follow suit.
With all the big players using DNSSEC and DANE, you can expect close to universal deployment, and that will be a game changer for Internet security.
None of this would have happened without Viktor Dukhovni's incredible effort these past several years. He built a survey of DANE usage so as to find brokenness and get it fixed -- long-term brokenness would have caused the protocol to get abandoned. Once the big players have DANE support, them and everyone else will have huge incentive to monitor their own domains for breakage, which will make breakage a rarity.