
First-ever DNSSEC root key rollover - danyork
https://www.redhat.com/en/blog/what-you-need-know-about-first-ever-dnssec-root-key-rollover-october-11-2018
======
tptacek
This was supposed to have happened a year ago (I think almost to the day?),
but was aborted roughly a week before because nobody was confident the system
would survive. Apparently it did this time!

An unfortunate attribute of DNSSEC: nothing depends on it, to the extent that
you could almost certainly post the root private keys on Pastebin and not
cause a single mainstream site a problem. At the same time, _if you screw the
deployment of DNSSEC up_ , sites vanish off the Internet, like HBO Now did, on
Comcast, the week of its debut.

Here's a fun exercise. In the thread below, someone brought up
[https://dnssec-name-and-shame.com](https://dnssec-name-and-shame.com)
(warning: makes annoying noises). Try to find the largest commercial site on
the Internet you can that has adopted DNSSEC. Try, for instance, tech giants,
or national banks and financial institutions. (Do you want me to spoil this
for you?)

Ultimately, this key rollover is sort of interesting in a network nerdery kind
of way, but it is no practical importance to anyone, because, after almost 3
decades of attempts, DNSSEC is over; stick a fork in it.

~~~
Abekkus
Big five tech giants aren't playing, and I don't know any bank domains, but
it's not hard to find names:

cloudflare.com verisign.com comcast.net *.gov

Every time dnssec shows up there's a tptacek comment crapping on the medium.
are you using google alerts or something? what were your consulting fees for
this service?

~~~
alwillis
_Every time dnssec shows up there 's a tptacek comment crapping on the
medium._

I know, right? Glad I’m not the only one to notice…

~~~
tialaramex
For example Thomas likes Let's Encrypt but he's stuck with his narrative about
how nothing uses DNSSEC. So when you point out that Let's Encrypt uses DNSSEC
so this position makes no sense, Thomas will just pretend not to understand
and refer you back to stuff he wrote many years ago about how nothing uses
DNSSEC.

~~~
tptacek
LetsEncrypt _does not_ rely on DNSSEC and does multi-perspective DNS lookups.
Something significantly south of 0.5% of LetsEncrypt certificates ever involve
DNSSEC.

If DNSSEC vanished tomorrow, literally nothing about LetsEncrypt would change.
There would be no operational impact whatsoever.

Not that there's anything wrong with the pieces I wrote "years ago" about
DNSSEC (nothing material has changed about it since I wrote that), but I
didn't do that here: I provided _new_ evidence that nobody is using DNSSEC,
and it is up-to-the-minute. Practically no mainstream sites use DNSSEC, as
everyone can see for themselves at the link at the root of this thread.

~~~
tialaramex
Those "multi-perspective" validations have been stalled for over a year. The
last news is from August 2017. Unlike many issuers Let's Encrypt notoriously
does fresh validations for most issuances and they start with a DNSSEC
validated authoritative DNS query chain. So, that's 100% of validations, and
perhaps 95% of all issuances. Not 0.5% as you've claimed.

When you wrote your jolly screed against DNSSEC the biggest CAs relied heavily
on "Any other method" blanket exemptions which no longer exist today. They
also used to insist that their extremely high issuance rates made DNSSEC and
other security features just infeasible.

After CT this last part got awkward. Where, a neutral party like me might ask,
are the doubtless hundreds of millions of certificates you've been issuing
that would make this so hard? And of course they don't exist, it was a bluff
and now their bluff has been called.

~~~
tptacek
An infinitesimal fraction of the domains LetsEncrypt issues certificates for
are signed. I kind of don't understand how you're even trying to make this
argument. Everyone here who has ever set up LetsEncrypt knows there's no
DNSSEC involved. LetsEncrypt does not depend on DNSSEC; if DNSSEC vanished
tomorrow, there would be no operational impact.

Here, try this: search for "LetsEncrypt tutorial", go through the first two
search pages, and find _one_ that says "to start with, sign your domain with
DNSSEC". Not one in my search results mentions DNSSEC. That's because: nobody
cares.

~~~
tialaramex
DNSSEC not protecting those who choose not to be protected is entirely to be
expected.

Should I assume you figured "nobody cares" about the Web PKI back just a few
years when tutorials wouldn't have mentioned TLS? Were people who said that
right? Or wrong?

~~~
tptacek
I'm sorry, I can't understand what you're trying to argue at this point. My
argument is simply that LetsEncrypt doesn't depend on DNSSEC, and, indeed, it
does not.

~~~
tialaramex
Me describing how these conversations go: > Thomas will just pretend not to
understand

Thomas just now: > I'm sorry, I can't understand what you're trying to argue

Let's Encrypt does today depend on DNSSEC because it uses a DNSSEC verifying
validator. If you have chosen not to sign names of course your names aren't
protected by this, names which are signed are protected.

In a similar way, Firefox does today depend on the Web PKI because it uses
NSS, a TLS implementation with a certificate validator baked into it. If you
have chosen not to use HTTPS of course your sites aren't protected by this,
sites which use HTTPS are protected.

~~~
tptacek
You're simply using a different definition of "depend" than I am.

When you say "it does depend", you mean that in the rare cases where a domain
owner has chosen (weirdly) to sign with DNSSEC, LetsEncrypt will enforce
DNSSEC validation on that domain.

When I say "it does not depend", I mean that the basic functioning of
LetsEncrypt does not in any way rely on DNSSEC. As I've said in the last
several comments, LetsEncrypt will continue to function just fine when DNSSEC
goes away, and a security failure in DNSSEC (for instance: if the root keys
were posted to Pastebin) would literally not impact LetsEncrypt --- today's
LetsEncrypt! --- at all.

I'm fine with you using the word "depend" to mean "uses, in any situation,
ever", but you're clear now on what we're trying to say, and the semantic part
of the debate should be over.

------
ars
What is the purpose of rolling over the key, if the new key is simply signed
by the old one? Meaning it has exactly as much security as the old key did.

I can understand it if the new key was a different algorithm, or key-length or
something. But what is the purpose in simply picking a new key?

~~~
tialaramex
The new key is simply newer. For especially valuable keys we must assume that
an adversary is trying to break them, even if this will be difficult and
expensive. But by changing keys, we undo all the work invested so far into
breaking a key, since the key they were breaking won't even be used any more.

This was the rationale behind password change frequency rules too. If I can
try 100 passwords per day, and I'm sure you've picked 1 of 1000000 passwords I
have a good chance to find which one in a few years. But if you're forced to
change it every 6 months then I'll never have more than a small chance to get
it.

Suppose it takes a government agency 25 years to break a key, and you replace
keys every 10 years. So they start on key A in year zero, in year 10 you
switch to key B, in year 20 to key C, and then in year 25 they've broken A -
but who cares everybody is using C now.

You might think well they could start working on C from the outset. No. The
keys are not chosen long in advance, you can't break C until it has been
chosen.

~~~
RL_Quine
> _This was the rationale behind password change frequency rules too. If I can
> try 100 passwords per day, and I 'm sure you've picked 1 of 1000000
> passwords I have a good chance to find which one in a few years. But if
> you're forced to change it every 6 months then I'll never have more than a
> small chance to get it._

This is not how probability works. Password rotation is intended to prevent
long term compromises from existing due to a leaked password. I'd debate if
this actually has any effect, but that's another matter entirely.

~~~
peterwwillis
> if this actually has any effect

It has the effect of limiting the amount of time that a credential leak can
lead to exploit. The focus is on long-term undiscovered compromise using valid
credentials. If an attack is not discovered, and the credentials are never
changed, the attacker might have access for years. If you're worried about
something like corporate espionage, this mitigation is simple and minimal
effort.

For really sensitive credentials, I would shrink the rotation period even
more. The more often you're forced to do it, the more likely the process will
become smoother.

~~~
RL_Quine
I argue that most compromises are effectively instantaneous. There’s usually
little value in being a persistent threat when it takes only a moment to, for
example, dump a database or an IMAP folder. Forcing rapid rotations just
encourages people to choose weak passwords or store them on post it notes on
their screen.

~~~
snowwrestler
And groups that value persistence (like APTs) rarely depend on passwords to
provide it. Instead they map the environment and find a local vulnerability to
exploit and create a place to hang out.

One of my employers had the Chinese in their networks for years. We all
dutifully changed our passwords every 90 days and it made no difference at all
to the Chinese persistence.

~~~
RL_Quine
Right. The classic is an email account is compromised, a forward to rule is
added, and nobody ever notices. It’s a false sense of security if preventing
persistence is the goal. Usually instantaneous access is going to be the most
disastrous effect anyway.

------
ancarda
I have a DNSSEC signed zone, do I need to do anything? Like generate a new key
using this new root key?

~~~
dchest
No, because nobody really depends on DNSSEC, so nothing will break:

\- [https://ianix.com/pub/dnssec-outages.html](https://ianix.com/pub/dnssec-
outages.html)

\-
[https://twitter.com/tqbf/status/772103926258671618](https://twitter.com/tqbf/status/772103926258671618)

~~~
rossy
> _because nobody really depends on DNSSEC_

That's not true. A lot of people use DNSSEC validating public resolvers like
1.1.1.1 and 8.8.8.8, especially on Android devices. I use DNSSEC on my
personal domain, and when my zone-resigning cronjob fails, I notice pretty
quickly, because the page really does fail to load in my browser.

~~~
dagenix
Is that a good thing? That sounds like a pretty solid reason not to deploy
DNSSEC.

~~~
tptacek
It's not a good thing. To a first approximation 0% of the mainstream public
Internet relies on DNSSEC, so using a DNSSEC-validating resolver will on net
get you only new outages; not any additional security, even at the margin.

It's a failed protocol that a subset of Linux nerds cheerlead because any
classic Internet protocol + "SEC" must be cool, that companies like Cloudflare
cheerlead because it's complicated and drives lock-in for them, and that
governments cheerlead because it in theory grants control over all web crypto
to them.

~~~
codebje
You can't have DNSSEC outages if no-one is validating DNSSEC. So either there
are outages, but a little extra security, or no extra security, but no
outages, either.

~~~
tptacek
Sure you can. Virtually no part of the web PKI takes advantage (or ever will
take advantage) of DNSSEC. Having DNSSEC enabled on your domain will
accomplish nothing for you. But: if you misconfigure DNSSEC, or fail to
maintain it, your site will vanish from the Internet for the users that make
the mistake of using DNSSEC-validating resolvers. You've gained no security,
but you have gained additional outages.

~~~
colde
Of course you gain security, but not in the HTTPS PKI sense. Not that long
ago, somebody BGP hijacked Route 53 in order to serve up different IP's for
specific domains. Had that domain been using DNSSEC, that attack would have
failed for everyone using a validating resolver. That might not be a common
attack, but it certainly grants security.

This could also help with "rogue" free wifi setups, that try to do something
like that as well.

~~~
the_clarence
Were the domains using TLS?

~~~
nybble41
Does it matter? If the attackers can redirect the domain names to their own IP
addresses then they can obtain DV certificates for those domains. The security
of TLS depends on secure domain name resolution.

~~~
tptacek
1\. Virtually nobody signs zones today, so this is a moot point.

2\. Not all DV-issuing CAs reliably verify DNSSEC, so it's even mooter.

3\. Even if everyone signed their zones today, the Five Eyes intelligence
agencies (NSA, ASD, GCHQ, GCSB, and CSE) have _de facto_ (and, in some cases,
_de jure_ ) control over the most important TLD zones.

4\. The Web PKI already has countermeasures in place to detect misissuances,
and those countermeasures have already resulted in the deaths of several of
the largest CAs; there is ample evidence that current Web PKI surveillance is
up to the task.

5\. Even with secure DNS resolution, DV cert verification processes _don 't
have a secure channel_, and remain vulnerable to traffic interception attacks;
for instance, even with DNSSEC, BGP attacks can straightforwardly trick CAs.

6\. There are countermeasures to DNS spoofing that are simpler to deploy than
DNSSEC, especially in the limited settings needed for DV cert verification;
for instance: multi-perspective DNS and DNS over HTTPS.

7\. There is already work happening to link CAs directly to registrars using
RDAP to bypass DNS entirely for domain validation. In addition to being _more
reliable than DNSSEC_ , RDAP is also drastically simpler to deploy, and
doesn't require anyone to sign their zones.

DV certificate issuance and SMTP-TLS were the last two mainstream drivers for
DNSSEC adoption. The Web PKI has worked around the problem, and, with SMTP-STS
(a standard whose _specific, stated rationale_ is to work around DNSSEC), so
have the largest email providers.

In fact: _nothing_ depends on secure domain resolution, all meaningful
Internet protocol security work over the last two decades has been premised on
DNS being insecure, and DNSSEC is done. Stick a fork in it.

~~~
tialaramex
> Even with secure DNS resolution, DV cert verification processes don't have a
> secure channel, and remain vulnerable to traffic interception attacks; for
> instance, even with DNSSEC, BGP attacks can straightforwardly trick CAs.

3.2.2.4.7 just does DNS, so DNSSEC can secure it regardless of "traffic
interception" or other shenanigans.

Tightening up the Web PKI happens gradually. In 2017 we required the Ten
Blessed Methods (3.2.2.4.x) to replace a previous free-for-all, and then we've
whittled away those ten so that today there are only eight left, of which one
is secured by DNSSEC and several are out-of-band, so shenanigans on the
Internet won't help you there. I won't be surprised if it's six by late next
year.

------
edoceo
But when will it be supported in Route53?

~~~
dagenix
But why do you want it? DNSSEC and TLS cover much of the same use cases -
except DNSSEC is worse. IIRC, it uses 1024bit RSA keys - which are large, and
yet not particularly strong. It gives you very little flexibility - if you own
example.com, you have to trust the root key and Verisign and whatever
governments have authority over them and the only way out is to change to a
different domain name. And what seemed like the most interesting technology
enabled by DNSSEC (DANE) has no browser uptake (for good reason).

~~~
phicoh
If your attack model includes Verisign or a government modifying your DNS
zone, then that will allow them to obtain a DV certificate as well.

By and large, TLS security depends on the connectness of DNS. Though you could
try your luck with HTTP public key pinning (HPKP).

I fully agree that 1024 bit keys are silly.

~~~
zamadatix
HPKP is about to only be usable on Firefox since IE/Edge never supported it
and Chrome has deprecated and is about to remove it.

------
anon49124
To check DNSSEC:

[https://dnssec-name-and-shame.com](https://dnssec-name-and-shame.com)

To check DANE (such as freebsd.org port 443):

[https://www.huque.com/bin/danecheck](https://www.huque.com/bin/danecheck)

~~~
jrockway
The dnssec-name-and-shame site makes an incredibly loud noise if the site you
type in happens to not be compliant or whatever. Be sure to remove your
headphones before clicking any links in the above comment.

