Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The DNSSEC Root Signing Ceremony

cloudflare.com

Post reply on HN
Print view View original

41–49 of 49 posts

Re: The DNSSEC Root Signing Ceremony

#41

Post by scintill76 »

cesarb wrote: post #37
mjevans wrote: post #29

Earlier quoted context omitted.

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.

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.

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.

Re: The DNSSEC Root Signing Ceremony

#42

Post by SolarNet »

ge0rg wrote: post #38

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.

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

Re: The DNSSEC Root Signing Ceremony

#43

Post by PinguTS »

scintill76 wrote: post #16

> 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…

I agree. The interesting thing here is not even code injected into the laptop, but about fake writes.

Because the article states, that Verisign provide their KSR via the USB, which is than is PGP signed and that signature is checked visually.

But what about, when the DNSSEC signatures are written to the USB stick, which then is handed over to Verisign to be implemented. They are also checked visually? Or can the USB stick (the implemented logic) forge the write and basically modify the written results?

Re: The DNSSEC Root Signing Ceremony

#44

Post by scintill76 »

PinguTS wrote: post #43
scintill76 wrote: post #16

> 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…

I agree. The interesting thing here is not even code injected into the laptop, but about fake writes. Because the article states, that Verisign provide their KSR via the USB, which is than is PGP signed and that signature is checked visually. But what about, when the DNSSEC signatures are written to the USB stick, which then is handed over to Verisign to be implemented. They are also checked visually? Or can the USB…

I don't understand the purpose of such an attack. The USB stick can't forge a signature (not even the laptop has the key -- it's in the HSM.) If it corrupted the signature by lying about the writes, they could just re-write on new media.

Re: The DNSSEC Root Signing Ceremony

#45

Post by mdk754 »

the8472 wrote: post #40
escape_goat wrote: post #18

Earlier quoted context omitted.

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…

> I had gotten the impression that the firmware vulnerabilities of USB flash drives had proven to be inherent, unavoidable, and utterly devastating My understanding is that it requires cooperation from the kernel. USB itself does not automatically allow DMA, but a driver can instruct the host controller to handle packets via DMA. So if you blacklist all device types (input devices) except the SD card and the driver f…

> I assume they transfer it to local storage first before signing it so that a potentially malicious storage device can't pull a switcheroo.

In the article they mention it doesn't have local storage. It's too bad they didn't go into more detail about tamper proofing the USB portion of the ceremonies.

> This laptop has no battery, hard disk, or even a clock backup battery, and thus can’t store state once it’s unplugged.

Re: The DNSSEC Root Signing Ceremony

#46

Post by Veratyr »

mdk754 wrote: post #45
the8472 wrote: post #40

Earlier quoted context omitted.

> I had gotten the impression that the firmware vulnerabilities of USB flash drives had proven to be inherent, unavoidable, and utterly devastating My understanding is that it requires cooperation from the kernel. USB itself does not automatically allow DMA, but a driver can instruct the host controller to handle packets via DMA. So if you blacklist all device types (input devices) except the SD card and the driver f…

> I assume they transfer it to local storage first before signing it so that a potentially malicious storage device can't pull a switcheroo. In the article they mention it doesn't have local storage. It's too bad they didn't go into more detail about tamper proofing the USB portion of the ceremonies. > This laptop has no battery, hard disk, or even a clock backup battery, and thus can’t store state once it’s unplugge…

It doesn't have persistent local storage but it does have RAM.

Re: The DNSSEC Root Signing Ceremony

#47

Post by JdeBP »

natch wrote: post #24

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.

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. (-:

Re: The DNSSEC Root Signing Ceremony

#48

Post by chimeracoder »

wtallis wrote: post #21
icebraining wrote: post #20

Earlier quoted context omitted.

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

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.

> 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 (not even https://) will never redirect to a captive portal. That's not DNSSEC. That's TLS + HSTS. DNSSEC is redundant in this situation.

Re: The DNSSEC Root Signing Ceremony

#49

Post by wtallis »

chimeracoder wrote: post #48
wtallis wrote: post #21

Earlier quoted context omitted.

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.

> 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 ve…

> [...] 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).

Post reply on HN