
The DNSSEC master key securing DNS is about to change - jonbaer
http://www.techworld.com/security/dnssec-master-key-securing-dns-is-about-change-should-we-be-worried-3645538/
======
tptacek
Nothing about DNSSEC should concern you other than the prospect that it might
someday actually be deployed.

[http://sockpuppet.org/blog/2015/01/15/against-
dnssec/](http://sockpuppet.org/blog/2015/01/15/against-dnssec/)

~~~
_jomo
I wonder why moxie's Convergence [0] didn't take off. To me it sounds near-
perfect. It could handle multiple layers of authenticity, including DNS.

The project has been inactive on GitHub for 5 years [1], however the Namecoin
project picked it up [2] as "FreeSpeechMe" and added support for IPv6, and
.bit, .onion, .b32.i2p domains. Now this, too, has been discontinued "because
Mozilla removed the relevant API's as of Firefox 33". They "intend to release
a replacement soon". According to Jeremy Rand [3] "A replacement is in the
works (and is mostly working already)", but the source doesn't seem to be
public or I can't find it.

Are there any downsides of Convergence?

0:
[https://www.youtube.com/watch?v=Z7Wl2FW2TcA](https://www.youtube.com/watch?v=Z7Wl2FW2TcA)

1:
[https://github.com/moxie0/Convergence/](https://github.com/moxie0/Convergence/)

2:
[https://github.com/namecoin/Convergence/](https://github.com/namecoin/Convergence/)

3:
[https://twitter.com/biolizard89/status/712525859194798080](https://twitter.com/biolizard89/status/712525859194798080)

~~~
StavrosK
IIRC, Google didn't want to run it because they'd end up running all the
notaries themselves, which they didn't want to do.

~~~
_jomo
So according to this and CiPHPerCoder's comment, the only reason it didn't
take off is that it didn't take off?

 _Edit_ : found the comment from Adam Langley [0]. They didn't want to add it
to Chrome because it wouldn't meet standards for the preferences UI inclusion,
practically everyone would just rely on the default notaries, so Google would
have to guarantee notary uptime, thus being forced to run them on their own.

He doesn't really point out why they don't include it as an optional
alternative without any notaries pre-configured. He does however say that
running it as an extension would be fine, but the required APIs weren't
available at the time of writing.

0:
[https://www.imperialviolet.org/2011/09/07/convergence.html](https://www.imperialviolet.org/2011/09/07/convergence.html)

------
verandaguy
> `Should we be worried`

I don't understand why that's in the headline outside of being clickbait. The
article itself mentions that meetings of the DNSSEC key holders are quarterly
and regular, and that the hardware involved in the actual key rollover
complies to the highest level specified by FIPS-140 (presumably actually
FIPS-140-2).

I don't believe there's reason to be worried; the ICANN has historically taken
reasonable precautions to ensure the safety of such meetings and exchanges.

~~~
madeofpalk
...I think they mean 'should we be worried' that DNS will break due to the
change. The article didn't really answer that though, instead just outlines
the ceremony that takes place.

Does the key change frequently?

~~~
bluejekyll
No, it doesn't change frequently. The article mentions that this is the first
time it's changing.

------
hannob
"The DNSSEC master key securing DNS is about to change. Should we be worried?"

No. Why should we be worried about anything in a protocol which has a
deployment status close to zero on the client side?

~~~
bluejekyll
Exactly. Does anyone know of any standard deployments that actually have the
clients verify the DNS key chain?

~~~
kijeda
That depends on how you define a client. If you're a Comcast customer, for
example, they are performing DNSSEC validation for you transparently.
Recursive resolvers on most Linux distributions have DNSSEC validation by
default.

One school of thought is to migrate DNSSEC from relying on validating
resolvers sitting within the network provider, and moving it closer to the
edge, in web browsers and so forth. Not much of that has happened to date.

~~~
snuxoll
> One school of thought is to migrate DNSSEC from relying on validating
> resolvers sitting within the network provider, and moving it closer to the
> edge, in web browsers and so forth. Not much of that has happened to date.

Fedora is actively working to including a system-local DNS resolver by default
that will validate DNSSEC-signed zones. The change was originally slated for
F24 but was deferred due to lack of resources, but I suspect it should make it
in by F26/F27 if all goes well and some of the NAT64 issues that were
discovered with Unbound are fixed.

~~~
hannob
What Fedora plans to do is to use a local resolver with a fallback in case
DNSSEC doesn't work. By this trick they try to prevent the inevitable
deployment problems of DNSSEC. Of course they also make it completely insecure
and it doesn't make any sense.

~~~
snuxoll
The fallback is to be configurable, but breaking the entire UX is not
desirable when a full recursive resolver is unable to function. Personally, I
would like to see some indication as part of the GNOME Network icon whether
the resolver is secure or not, but I have a hard time determining what that
would look like and how to implement it without giving users false assurances
or worrying them if they don't care.

It's a tricky problem to solve, but Rome wasn't built in a day either. I'll
probably disable the insecure fallback myself and only turn it on when I
connect to my work VPN, I already don't trust public hotspots so unless I can
connect to my OpenVPN server at home I don't use them.

------
guessmyname
What is the security like in these meetings? Is any security agency taking
part on these ceremonies? What is preventing a terrorist group to launch an
attack against this people considering the importance of all of them? I am
probably exaggerating because all this reminds me of the not-so-old movies
about hacking a la "Mission: Impossible" film series. Do they say that the
meeting is going to take place in one place — like in the article it says El
Segundo, CA — but actually meet elsewhere? Do the key holders have security
24/7 in their respective countries to prevent stolen keys?

Again, I am misunderstanding the information here, but the keys are actually
useless, even if you get your hands on all of them to attempt an incursion
against the building where the KSK is, you would not be able to do anything
because the security of that place is probably good enough to counter an
attack like that, and supposing the attack takes place the other DNS servers
would simply disconnect from the root and serve the information that they have
until it gets outdated. So the only scenario that I can picture in my head is
one where a terrorist attack goes against the building to disrupt the
functionality of the whole system for anarchy reasons.

~~~
kijeda
The security is designed to guard against surreptitious access. Interested
members of the public are welcome to attend ceremonies (availability on a
first-come first-served basis).

There are multiple redundant sites and backups of the keys, so an attack aimed
at destroying a site should not alone be a problem. Even if all all sites and
backups were destroyed, there is a window where a new key can be constructed
(approximately between 3-6 months worth of operational zone-singing keys are
prepared in advance for the root zone).

~~~
CiPHPerCoder
One window of vulnerability is the after-party where everyone with a piece of
the signing key drinks cocktails together.

~~~
kijeda
Ceremony attendees don't leave with part of the signing key.

Despite the folklore around these ceremonies that there are 7 people with "the
keys to the Internet", those seven only retain a metal key that is used to
access a safety deposit box in the ICANN/IANA facility, each of which contains
a smart card of which there is an "m-of-n" configuration to activate HSMs
containing the actual key.

~~~
CiPHPerCoder
Thanks for the correction. :)

------
ryanlol
I'm not sure if the author really understands just how irrelevant DNSSEC is as
of right now.

~~~
runjake
I don't know why you're being downvoted into oblivion.

This is a legitimate observation. When I saw the submission title, I
momentarily thought "Huh? Did DNSSEC finally take off?".

Spoiler: The answer is no. There are more effective ways to deal with security
at the higher layers of the OSI model (such as relying on TLS
encryption/identity).

~~~
bluejekyll
While this is true, what DNSSec solves is the distribution of trusted
identity.

It's one of the lowest layers in the Internet, if you can hijack DNS, then all
connections the client is routed to can be used to exploit higher level
security features like TLS. Yes, things like pinning of certificates can
reduce this, but all a bad actor needs to do is get access to a poorly managed
x509 trusted cert.

DNSSec does offer a layer of trust that most people lack today.

~~~
tptacek
You trust Verisign? You trust the USG? You trust the UK?

DNSSEC was hijacked --- by old-school Unix people in the IETF who loathe X.509
on aesthetic grounds and by the USG, which attempted to mandate DNSSEC --- to
integrate with and replace X.509 CAs.

You write as if DNSSEC could be deployed alongside the X.509 CA hierarchy. No.

On the real-world Internet, browser trust validation has to work for everyone,
or it doesn't work at all. Common-sense workarounds, like "we'll do DANE for
the people who can do DANE, and then fall back to CA validation" fall apart
when confronted with adversaries. Anything you "fall back" to becomes the
default for purposes of security, because attackers will launch downgrade
attacks to make that happen.

Don't take my word for this:

[https://www.imperialviolet.org/2015/01/17/notdane.html](https://www.imperialviolet.org/2015/01/17/notdane.html)

The net result is: DANE doesn't collapse Internet trust down to a single
point; rather, it provides us with a 1036th CA. One that just happens to be
run by world governments.

~~~
bluejekyll
If I understand your basic argument, it's that shit is broken, and so fuck it,
we'll just not bother with it. At what point do we decide that we should fix
it?

New DNS record types not being returned, yes this sucks, it means there are a
lot of firewalls and resolvers that need to be fixed. But IPv6 has the same
upward battle in terms of router support, finally making a lot of headway. As
people start demanding DNSSec, anything that is blocking that will need to be
fixed.

RSA 1024 keys should be replaced, but again, we should be working to fix this,
should we not?

> it provides us with a 1036th CA. One that just happens to be run by world
> governments.

Validating a different set of data though. On top of that, TLD's can start to
be ranked based on their reputation.

Just because things don't look good right now, doesn't mean that we can't work
to fix them and make them better. Similarly we need to start pushing for BGP
to get secured, as attacks on that network are significantly on the rise. I
don't think we should just ignore the lower stacks of the network.

~~~
tptacek
DNSSEC has no meaningful real-world deployment. Nobody on the entire Internet
has ever been protected by a DNSSEC validation. So if we're just going to fix
things and make them better, _let 's fix the protocol_, instead of deploying
something that is broken and obsolete before anyone even starts using it.

~~~
bluejekyll
Do you have any specific recommendations? Or something to point me to? I'd
love to help _fix the protocol_.

~~~
tptacek
Sure. DNSSEC was designed in the early-mid 1990s on the premise of "pick two:
offline signing, authenticated denial, secret hostnames". They picked offline
signing and authenticated denial. They picked wrong: the protocol should be
redesigned to assume online signers, taking advantage of cryptography in every
transaction.

Obviously, DNSSEC should provide query secrecy. Obviously, every DNSSEC
transaction should be encrypted. That's functionality not present in DNSSEC
that must be before the protocol can be taken seriously. Resolver-server
encrypted transactions also solve the problem of endpoint signature validation
(because there's no weak link between servers and clients anymore).

Daniel Bernstein, among others, was smart enough to realize that if you
encrypt the connection between a resolver and a server, _you don 't really
even need signatures anymore_: if every link in the resolution chain is
encrypted, there's no straightforward place to launch spoofing attacks
anymore. DNSSEC advocates will point out that this doesn't make injecting fake
DNS records 100% impossible. But it makes it so difficult that it's not worth
it to any plausible attacker.

There's nothing you can do about the fact that DNS is a hierarchical PKI
controlled by governments. DANE simply can't be made to work: DNS has no
business holding TLS certificates.

~~~
bluejekyll
I think I completely agree with you:

> the protocol should be redesigned to assume online signers, taking advantage
> of cryptography in every transaction.

When you say online signers, do you mean not actively storing RRSIG records
for RR sets at all? Or do you mean dynamically resigning the zone after any
update? I think there is a benefit to these records in validating they
originate with zone from which they claim to be. The biggest concern I have
right now with the protocol is that having multiple nodes being responsible
for managing a zone is difficult because each has to be signed by the parent
zone, though with the necessary automated support, this shouldn't be hard to
overcome (i.e. makes HA harder).

> Resolver-server encrypted transactions also solve the problem of endpoint
> signature validation (because there's no weak link between servers and
> clients anymore)

Do you have any thoughts on DNS over TLS vs DNSCrypt? I got halfway through
implementing DNSCrypt, but I have some concerns about it being easily
exploitable for DOS attacks. And am switching to DNS over TLS for now.

> Daniel Bernstein, among others, was smart enough to realize that if you
> encrypt the connection between a resolver and a server, you don't really
> even need signatures anymore...

Yes, this is true, but the concerns I've had with this are 1) ability to cache
data and 2) ability to add nodes to the network. While I completely agree with
this, we need to come up with a method that allows new nodes to be added to
the graph, which might be cumbersome from a resolver perspective. In terms of
zone authorities it should be relatively straightforward though. With the
current DNSSec design, it allows for trusted data to be stored on untrusted
nodes in the graph, making cached data straightforward.

If you don't mind, I'd love your feedback on a project I've been working on
for the last year: [https://github.com/bluejekyll/trust-
dns](https://github.com/bluejekyll/trust-dns)

I want to try and deal with many of these aspects of the protocol, from the
slant of making it easier to setup and operate. I currently don't have a lot
of documentation around operations, as I'm still focused on implementing some
things like DNS over TLS. I'd love to bake some of these concepts into the
software, so if you have any feedback that would be awesome.

------
ikeboy
>The same ceremony will be repeated at the secondary master key facility in
early 2017 before being used in anger for the first time at a third get
together in Q2.

Is this a typo, or there some reason they're going to be angry?

~~~
jloughry
"...used in anger" means used for the purpose it was intended for, not just in
testing or rehearsal.

The analogy is to a spear or a gun; when used in anger, it is used to hurt
somebody.

------
SubiculumCode
"This is only the beginning. The same ceremony will be repeated at the
secondary master key facility in early 2017 before being used in anger for the
first time at a third get together in Q2."

???

------
ComodoHacker
Interesting but ridiculous approach to hiding content because of ad blocking:
set the article's font to "redacted_scriptbold".

~~~
technofiend
Particularly when you have no control over the ad blocking.

------
jmartinpetersen
Yet another site that confuses an ad blocker with a privacy guard. Is there
some kind of pre-canned explanation or site I can point them at?

------
noinsight
What type of key is it going to be, RSA or ECC? The article omits that detail.
ECC would be a huge step forward...

~~~
kijeda
It is going to be 2048-bit RSA, same as the existing. It was considered
rolling the key for the first time would be complex enough that tracking the
effects of an algorithm change as well probably should wait for a future
opportunity.

------
bugmen0t
TLDR: No.

------
misterpigs
'No'

