5 ms·
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
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.
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.
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.
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.
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!
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-also-be-put-out-of-our-misery/ 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.
Which makes this:
> Authenticated denial. Offline signers. Secret hostnames. Pick two.
wrong.
> DNSSEC is Architecturally Unsound
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.