
The DNSSEC Root Signing Ceremony - jgrahamc
https://www.cloudflare.com/dnssec/root-signing-ceremony/
======
Fuzzwah
I can imagine a Neal Stephenson book which makes a number of 50 year jumps
into the future and explains how this ceremony becomes more and more religious
in nature. Toss in a few dramatic changes based on either fanciful ideas of
new ways to compromise the process or in reaction to actual attack attempts
(or successes).

------
scintill76
> The only way to move information from the outside world into the laptop/HSM
> is via USB drive. Accordingly, the key-signing request is loaded into the
> laptop via USB.

Hmm, how sure are they that the OS only allows USB drives (as opposed to
keyboards, network controllers, etc.), and contains no exploitable bugs? Is an
image of the media the laptop was booted from publicly available, and has it
been audited?

I almost feel silly asking, given all the time spent designing this and how
smart the people are, but after all that trouble it seems amateurish to use
USB...

~~~
escape_goat
I too do not know enough to not feel silly for asking this, but I have a
similar feeling, and I am not sure if I have misunderstood the past year's
worth of popular articles on USB security, the risk posed by the USB in the
context of the ceremony, or both. I had gotten the impression that the
firmware vulnerabilities of USB flash drives had proven to be inherent,
unavoidable, and utterly devastating; that, basically, any given USB drive
could become a general-purpose bus-querying hostile computing device, if once
plugged into a machine controlled by a capable and motivated adversary.

If that understanding was correctly received, and given the strength of
potential motivation involved here, my thought is that the problem presented
by the USB drive could only be combated by (a) ensuring that the USB drive was
obtained in a random enough fashion that vast numbers would need to be
deliberately compromised with this specific target in mind for that approach
to be feasible, and (b) ensuring that the USB drive was neither ever
unsupervised nor connected to any USB port (except one on a "known-to-be-
clean" computer) after the selection occurred.

The problem that I see with those measures is that if compromising the laptop
with a compromised USB drive were possible, then the actual security of the
process would be purely dependent on the security of measure (b), as
established by a single actor at the ceremony: that is, whomever provides the
USB with the key-signing request. This last point just by itself would seem to
be a degree of risk well beyond the criteria implied by the established
protocol.

~~~
mjevans
Couldn't you just use an actual device medium?

The fact that a burnable CD should have no parts that can think actually makes
using one for input and one for output probably safer (though you would then
need the trusted application to include a CD/DVD burning capability).

As an alternative, a 'raw' interface, such as an actual programmable flash
device or maybe an SD card could work.

~~~
cesarb
Doesn't the laptop boot from the DVD drive? If it's already busy being used
for the operating system, it can't be used for input/output.

~~~
scintill76
Add another optical drive. The USB they've already got would probably be OK,
as an optical disc is more "inert" than a USB flash drive.

Or, you could probably copy the OS from the initial DVD to a ramdisk, allowing
to insert a new disc to load data from.

------
tptacek
_Access requires the cooperation of 7 individuals, all of whom must be present
for a Root Signing Ceremony to take place:_

 _The Ceremony Administrator_

 _An Internal Witness_

 _The Credentials Safe Controller_

 _The Hardware Safe Controller_

 _Crypto Officer #1_

 _Crypto Officer #2_

 _Crypto Officer #3_

Fascinating. What's the signing ceremony for .IO look like? .COM? .NET?
.CO.UK? .COM.AU?

~~~
Laforet
It will probably involve a similar roll of controllers, plus
supervisors/representatives from operators of all DNS root servers[0].

[0]:[https://lwn.net/Articles/647459/](https://lwn.net/Articles/647459/)

------
jcox92
The Guardian did a piece on this last year including a video of part of the
ceremony: [http://www.theguardian.com/technology/2014/feb/28/seven-
peop...](http://www.theguardian.com/technology/2014/feb/28/seven-people-keys-
worldwide-internet-security-web)

~~~
cstuder
And fun anecdotes like:

    
    
      At 21.29, things go awry. A security controller slams the door of the safe shut, triggering a seismic sensor, which in turn triggers automatic door locks. The ceremony administrator and the keyholders are all locked in an 8ft square cage.

------
cflee
The next KSK Ceremony is happening today (12 November 2015, 18:00 UTC):

[https://www.iana.org/dnssec/ceremonies/23](https://www.iana.org/dnssec/ceremonies/23)

------
ge0rg
Okay, so this tremendously complicated and secure ceremony is performed to
essentially sign a "Verisign is allowed to do whatever they deem appropriate
to the root of DNS in the next six months" certificate.

This is really just security theatre, as all the power is delegated to
Verisign, and it is almost impossible to detect Zone Signing Key abuse.

~~~
SolarNet
Except that verisign is also replaceable in this whole thing. If they ever
screw up they can easily be replaced.

------
natch
It's amusing that their plexiglass labeled holder for the OS DVD has OS
misspelled as O/S. I believe this misspelling most likely stems from people
having seen and slightly jumbled part of the name of the old IBM branded
operating system, OS/2.

~~~
JdeBP
It is a usage that has been fairly widespread in computing literature since at
least the early 1970s, pre-dating OS/2 by at least a decade and a half
(possibly more). Such abbreviations punctuated by slash have been acknowledged
widely even _without_ the realm of computing (and for decades longer) in quite
a number of manuals of punctuation and style. And they're still acknowledged
today. Merriam-Webster's _Pocket Guide to Punctuation_ and _New Hart 's Rules_
give examples of slash-punctuated abbreviations including N/A, c/o, w/o, and
A/C.

The amusing thing is to see it being mis-categorized a mis-spelling based upon
OS/2 of all things. You could at least have picked OS/360 or something. (-:

------
yeukhon
So they are actually holding a physical key? Am I misreading the article? I am
just imagining the case when people all get kidnapped...

How do you become the crypto officer? What are their credentials? How often do
you change the people?

------
larrysalibra
This silly signing ceremony shows the fragility of a centralized trust model.
If bitcoin/blockchain succeeds this hopefully will be relegated to the history
books.

------
ta0o0o0
So how is this logically different than the replacement of all CAs with a
single one?

~~~
admax88q
This was talked about a lot on the last DNSSEC story on HN. I don't have a
link to the story but this site was linked to from discussions.

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

DNSSEC does seem pretty unnecessary at this point for security. It hands more
power over the internet to fewer hands, whilst not providing any improved
security.

~~~
wtallis
DNSSEC only seems unnecessary under the assumption that you're already making
full use of existing security measures everywhere else in the stack. If you
live in a world where unencrypted HTTP still exists then it's nice to have
some defense against ISPs who like to lie in DNS responses. And even if I am
connecting over HTTPS through a shady ISP, I'd prefer not to send any packets
at all to the wrong IP rather than wait until it presents the wrong
certificate.

~~~
chimeracoder
> If you live in a world where unencrypted HTTP still exists then it's nice to
> have some defense against ISPs who like to lie in DNS responses.

As tptacek and others have pointed out numerous times elsewhere on HN (and in
the article linked above):

1\. DNSSEC doesn't protect against ISPs hijacking DNS responses

2\. TLS is easier to deploy than DNSSEC

3\. TLS provides more security for the end user than DNSSEC does

3a. If TLS us used, DNSSEC provides essentially no additional security
benefits to the end user.

So really, it makes sense to be advocating the use of TLS, which is what
projects like Let's Encrypt are all about. DNSSEC is at best a waste of
resources that could be better spent on actually securing the Internet through
TLS, and at worst actively harmful (because the strongest criticism of TLS is
that it centralizes trust in CAs, and DNSSEC centralizes trust even further -
in a _single entity_!)

> I'd prefer not to send any packets at all to the wrong IP rather than wait
> until it presents the wrong certificate.

I'm not sure what difference it makes to be sending packets to the wrong IP.
The whole point of TLS is that it doesn't really matter, because they can't
read what you're sending anyway.

Also, the way the Internet works, you're _always_ sending packets through the
"wrong" IP addresses, so you should make the assumption that your raw traffic
is visible to to any eavesdropper (and therefore encrypt your traffic so that
this is not an issue).

~~~
wtallis
> 1\. DNSSEC doesn't protect against ISPs hijacking DNS responses

DNSSEC protects signed zones by allowing clients to notice a suspicious lack
of a valid signature on responses that should have been signed. DNSSEC doesn't
protect unsigned zones, but that shouldn't surprise anyone and isn't really an
indictment of DNSSEC's capabilities.

> I'm not sure what difference it makes to be sending packets to the wrong IP.

That malicious IP gets to record what kind of connection my computer was
trying to make to that domain, even if the connection attempt is aborted
relatively early. That's more information being leaked than if my computer had
been able to determine that it got a probably-spoofed DNS response and aborted
there.

Playing shenanigans with the DNS server is a lot easier than full-scale
snooping and tampering on all traffic, which is why ISPs commonly do the
former but the latter is usually only done with NSA involvement.

It needs to be _hard_ for ISPs to direct all mistyped domain names to their
own advertising (and in the process, implicitly pretending that the Web is the
only use for the Internet) or to claim that sites they don't like don't exist.
DNSSEC helps with that.

~~~
icebraining
But the clients' stub resolvers don't validate the answers, so how can they
notice the lack of a valid signature?

~~~
wtallis
Some clients don't validate. Some do. Everything on my home network is
protected because my router's instance of dnsmasq validates. When I'm away
from home, there's dnssec-trigger and a Firefox extension.

I really don't understand why the existence of software that doesn't try to
take advantage of DNSSEC is being used as evidence that DNSSEC is incapable of
doing something.

~~~
chimeracoder
> I really don't understand why the existence of software that doesn't try to
> take advantage of DNSSEC is being used as evidence that DNSSEC is incapable
> of doing something.

It's not that DNSSEC is fundamentally "incapable" of doing this, but that it's
literally not what the protocol is designed to do. As noted in the other HN
thread on this announcement, the DNSSEC protocol is explicitly _not_ designed
for end-user verification, and end-users are discouraged from running their
own valdiators. There's a reason that browsers don't support this out-of-the-
box and (more importantly) don't ever plan on it.

If you're concerned about people snooping on your TCP packets, DNSSEC doesn't
solve that. If you're concerned about people spoofing DNS responses, DNSSEC
doesn't solve that[0]. TLS + HSTS _does_ solve that, by making it impossible
to load a forged page, regardless of what DNS records were returned[1].

Again, TLS solves all the problems you describe (including the problem of ISPs
redirecting mistyped pages to their own advertising pages). TLS is also
supported by _every_ browser, out-of-the-box. It's more secure, easier to
deploy, and already widely used.

[0] Again, as explained in the post, DNSSEC is _not_ designed to protect end-
users against malicious ISPs. This is literally a matter of what problems
DNSSEC is even aimed at solving.

[1] Notice how [http://google.com](http://google.com) (not even
[https://](https://)) will _never_ redirect to a captive portal. That's not
DNSSEC. That's TLS + HSTS. DNSSEC is redundant in this situation.

~~~
wtallis
> _[...] but that it 's literally not what the protocol is designed to do._

> _the DNSSEC protocol is explicitly not designed for end-user verification_

> _This is literally a matter of what problems DNSSEC is even aimed at
> solving._

Repetition doesn't make that argument any more valid. If DNSSEC wasn't
intended to have this capability, it's for the same reasons that it wasn't
intended to be used for on-the-fly signing: it was designed in the mid-'90s
when that was impractical. Nowadays it _is_ practical and it _does_ in fact
work just fine for this purpose, and it provides an extra layer of defense in
depth and stops some attacks sooner than TLS can and provides some added
security to things that aren't using TLS (because remember, there's more to
the Internet than just the WWW, and many of those things don't have the
aggressive upgrade cycle that Chrome uses).

