[Cryptography] DNSSEC = completely unnecessary?

[Greg]

On Nov 5, 2013, at 1:08 PM, bmanning at vacation.karoshi.com wrote:

> reading this post suggests you really don't understand DNSSEC at all.

It's possible my understanding has holes in it. Like I said, I've been having difficulty finding "good" documentation for it (in quotes because "good" means something different to everyone). I've been coming across a lot of dead links too, and even links to sites with bad certs (irony).

I've been going off of several documents and articles. One is the one originally linked to at the start of this thread, and here are some others:

"DNSSEC-bis for complete beginners (like me)": http://ds9a.nl/dnssec 
"Seven Things You Should Know About DNSSEC": http://www.educause.edu/ir/library/pdf/est1001.pdf
"Introduction to DNSSEC": http://cai.icann.org/files/ssac/dnssec_explained_marrakech_28jun2006.pdf

And here are some quotes that led me to believe that the root plays a significant role.

From "Intro. to DNSSEC":

- "Make sure the root zone key can be trusted"
+- "Pointers in the root zone point to lower zones (com/org/info/de etc)"
+- "Each pointer is validated with the previous validated zone key"
- "Only the key for the root zone is needed to validate all the DNSSEC keys on the Internet"
- "How to update these keys and propagate them are not done yet"

From "Seven Things...":

- "The effort to implement DNSSEC for the root has renewed a longstand- ing debate about where “control of the Internet” resides."

- "With DNSSEC, a series of encryption keys are handed off and authenticated—the second-level domain (SLD) key (from exam- ple.edu) is authenticated by the TLD (.edu), and the TLD key is authenticated by the root. In this way, when an SLD, its parent TLD, and the root are all signed, a chain of trust is created. (Holders of SLDs can implement DNSSEC before their TLD or the root is signed, creating so-called “islands of trust” that rely on intermediate measures to validate their encryption keys.) If the encryption keys don’t match, DNSSEC will fail, but because the system is backwards-compatible, the transaction will simply follow standard DNS protocols.

The value of the system will come when the root, the TLDs, and SLDs are signed, allowing DNSSEC to be used for all Internet traffic. At that point, when DNSSEC fails, users will not be routed to bogus servers, and they might also be notified that nonmatching DNSSEC keys prevented their transaction from going through."

From "DNSSEC-bis for complete beginners...":

- "The second way is to have an existing 'anchor' sign your keys. In an ideal world the root-zone would be the anchor, and everything would flow from there."
- "We previously noted that we can designate keys as 'anchors', once we have verified their authenticity using non-DNS means. It is impracticable to do this for all millions of domains though. So we need a way to have trusted keys (anchors) sign further keys, in hopes of one day having a signed root."

So... I don't quite understand what you mean by:

> using the islands of trust model, _any_ client can trust any keys they choose


That sounds like manually adding root certs to your system's keychain to me. Nobody (other they neck-beards) does that. In practice, browsers come with pinned certs that they trust, and any of these root certs can say "yes". How will DNSSEC work in practice for users?

- Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131105/e4eb8f25/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131105/e4eb8f25/attachment.pgp>