
DNSSEC root key signing ceremony postponed because they can't open a safe - sohkamyung
https://www.theregister.co.uk/2020/02/13/iana_dnssec_ksk_delay/
======
Foxboron
>during what was apparently a check on the system on Tuesday night – the day
before the ceremony planned for 1300 PST (2100 UTC) Wednesday – IANA staff
discovered that they couldn’t open one of the two safes. One of the locking
mechanisms wouldn’t retract and so the safe stayed stubbornly shut.

I clicked randomly around in the linked livestream from November and came
across what seems to be them having problems with Safe 2. I'm amazed this is
streamed and they are actively showing the written pads towards the camera.

[https://youtu.be/erfsFJsapAs?t=680](https://youtu.be/erfsFJsapAs?t=680)

~~~
_-___________-_
You mean the paperwork they're holding in their hands? Is there something
secret on it?

~~~
Foxboron
It's for viewers to verify the work they are doing. I'm not implying they
shouldn't.

~~~
_-___________-_
Ah, thanks for the clarification. That's smart.

------
erik_seaberg
I'm reminded of a story about Google's internal password vault outage, where
restoring service required opening a safe whose combination was of course in
the password vault.

~~~
brokenmachine
How did they resolve it?

~~~
erik_seaberg
They expensed rubber mallets, which didn't work. They brought in a locksmith,
which did.

------
Spare_account
I'm surprised both of the key-signing locations are in the US. There should be
more locations in other countries.

~~~
saber6
It’s not a USG power play. It just so happens that a large portion of internet
engineers and architects live in the United States.

~~~
tptacek
But it's probably worth remembering that DNSSEC is a PKI over which the USG
and its Five Eyes partnership has enormous, outsized influence; they have de
facto custody over the most important TLDs on the Internet, a demonstrated
willingness to intervene in DNS for policy goals, and, unlike a suborned CA,
the TLDs cannot be revoked when the IC abuses them.

"Ceremony" is the right word for IANA's handling of the root zone, which is a
McGuffin in the Internet security model; the DNS roots won't be what the IC
targets.

~~~
saber6
> But it's probably worth remembering that DNSSEC is a PKI over which the USG
> and its Five Eyes partnership has enormous, outsized influence; they have de
> facto custody over the most important TLDs on the Internet, a demonstrated
> willingness to intervene in DNS for policy goals, and, unlike a suborned CA,
> the TLDs cannot be revoked when the IC abuses them.

You're off base.

DNSSEC is not any more nebulous than the existing structure and control
mechanism with regards to domain names. It (mostly) is adding cryptographic
under-pinnings to the responses. The control remains the same (registrar
level).

~~~
tptacek
I'm not off base, and the Five Eyes governments obviously control the most
important TLDs, as anyone who was around during the piracy seizures knows. The
control remains the same, yes: controlled by the USG.

------
sneak
Is the safe going to be drilled on the livestream in front of the witnesses?
Or are the key material devices and the HSM going to be accessed outside of
the ceremony for potential tampering?

Seems to me that exceptions and anomalies like this are the weak points of the
system. If I wanted to steal these keys, I would make an effort to create
anomalies like this where I might have physical opportunities to glitch the
keycards and exfiltrate the data without the whole internet watching me.

~~~
edf13
With a tinfoil hat on - how do you know the livestream isn't pointed at some
fake studio and the real safe hasn't already been tampered with?

~~~
pas
You never know, after all maybe your whole life just happens inside a big box
(or a small one if you are a simulated/real brain in a vat).

But if you accept that it's possible to gain some information, and to
basically slowly build up a model of the real, so you can start trusting
sources of information, eventually you can build a ceremony model and there
are designated witnesses, and designated key-holders. And in theory press
should regularly interview them to make sure they are trustful, mentally okay,
they are not blackmailed, or otherwise tampered with, and what they say about
the process, safe, stream, etc.

So in the end it's all about your priors. If you have an almost unmovable
belief about we're all just being lied to, then you might never (as in not in
<100 years) update to the alternative belief.

------
microtherion
The description of the ceremony is fascinating. Somewhat disappointed, though,
in the lack of pre-modern flourishes. No goats sacrificed? No pentagrams drawn
on the floor? No requirement for a full moon? Engineers don't have to take a
lifelong vow of chastity?

How do they ever expect a low-rent affair like this to work?

------
ElectronShak
>so that when you visit, say, theregister.co.uk, you eventually reach one of
our servers at network address 104.18.235.86.

More like you reach CloudFlare's CDN

------
zhte415
I'm both reassured by this, but also concerned. Reminded of a former employer
with the entire global data centre in one single location, quite a secure
location, but not very secure against bad actors, that could take down banking
across much of the world.

~~~
BrandoElFollito
This is the same case with travel reservations. It is surprisingly not
resistant to internal attacks and would be one of the top 3 most severe
disturbances in the world (I have a hard time imagining the other two - your
banking example is one of them, if they are indeed that centralized)

------
londons_explore
DNSSEC would only be of relevance if records could cryptographically sign TLS
certificates.

Since no browser today can do that, DNSSEC is a dead technology.

~~~
tialaramex
When you ask Let's Encrypt to do a dns-01 challenge for example in order to
obtain that TLS certificate, their resolver will do DNSSEC to determine either
that your challenge answer is authentic or that proof is available that your
zone isn't signed.

For everybody without a signed zone, it would be trivial for a resourceful
adversary to pass the challenge by simply interposing to give a bogus answer
to the query. Only people with DNSSEC actually get cryptographic security
here.

Whether it's surprising that most people (where "most people" includes big
banks for example) are comfortable with basically just relying on the honour
system as good enough is I suppose a judgement about how smart you think
people are or how much they actually care about security.

~~~
tinus_hn
So how are you going to ‘simply’ intercept their resolver requests from
multiple locations distributed globally? Not to say it isn’t an issue but it
is quite far in the theoretical realm.

~~~
throw0101a
> _So how are you going to ‘simply’ intercept their resolver requests from
> multiple locations distributed globally?_

Up until now, you only had to intercept one path:

> _On Wednesday February 19th, 2020 we’ll turn on stricter validation
> requirements 30 in production. We’ll make multiple validation requests from
> different network perspectives._

* [https://community.letsencrypt.org/t/112253](https://community.letsencrypt.org/t/112253)

------
masto
Where is the lock picking lawyer when you need him? A little click on 3, some
counter-rotation, and there you have it!

------
dependenttypes
DNSSEC you say? [https://sockpuppet.org/blog/2015/01/15/against-
dnssec/](https://sockpuppet.org/blog/2015/01/15/against-dnssec/)

~~~
caymanjim
That was written by a prolific anti-DNSSEC campaigner active here on HN. I
don't understand the system well enough to critique it, but between that post
and various comments on HN, I've stopped assuming that DNSSEC is a universal
good thing. Before I recently hardened my own email server and had to jump
through all the hoops to get DANE working, I thought that DNSSEC was actually
DNS-over-TLS with some sort of chain of trust back to the authoritative DNS
server, and was surprised to learn that it was none of those things. I'm still
going to use it but I'm not going to evangelize it the way I would if it
actually provided encryption and trust.

~~~
alwillis
_I 'm still going to use it but I'm not going to evangelize it the way I would
if it actually provided encryption and trust._

It was never supposed to encrypt lookup; that was mostly a disingenuous
strawman argument from the usual suspects.

It _does_ provide a chain of trust. By using the public key published in your
zone, a validating resolver checks the digital signatures from the root to
your zone.

It’s no different than when a browser checks the digital signatures on a
certificate that’s signed by an intermediate certificate that was signed by a
root certificate.

For authentication and trust purposes, every resource record in a DNSSEC-
signed zone is cryptographically signed and validating resolvers--Unbound,
Knot Resolver, BIND--confirm them.

