
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Nov 5, 2013, at 1:08 PM, <a href="mailto:bmanning@vacation.karoshi.com">bmanning@vacation.karoshi.com</a> wrote:<div><br><div><blockquote type="cite">reading this post suggests you really don't understand DNSSEC at all.<br></blockquote><div><br></div>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).<div><br></div><div>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:</div><div><br></div><div>"DNSSEC-bis for complete beginners (like me)": <a href="http://ds9a.nl/dnssec">http://ds9a.nl/dnssec</a> </div><div><div>"Seven Things You Should Know About DNSSEC": <a href="http://www.educause.edu/ir/library/pdf/est1001.pdf">http://www.educause.edu/ir/library/pdf/est1001.pdf</a></div><div>"Introduction to DNSSEC": <a href="http://cai.icann.org/files/ssac/dnssec_explained_marrakech_28jun2006.pdf">http://cai.icann.org/files/ssac/dnssec_explained_marrakech_28jun2006.pdf</a></div><div><br></div><div>And here are some quotes that led me to believe that the root plays a significant role.</div><div><br></div><div>From "Intro. to DNSSEC":</div><div><br></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>- "Make sure the root zone key can be trusted"</div></div><div><div>+- "Pointers in the root zone point to lower zones (com/org/info/de etc)"</div></div><div><div>+- "Each pointer is validated with the previous validated zone key"</div></div><div><div>- "Only the key for the root zone is needed to validate all the DNSSEC keys on the Internet"</div></div><div><div>- "How to update these keys and propagate them are not done yet"</div></div></blockquote><div><div><br class="webkit-block-placeholder"></div><div>From "Seven Things...":</div><div><br></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>- "The effort to implement DNSSEC for the root has renewed a longstand- ing debate about where “control of the Internet” resides."</div></div><div><br></div><div>- "With DNSSEC, a series of encryption keys are handed off and authenticated—the second-level domain (SLD) key (from exam- <a href="http://ple.edu">ple.edu</a>) 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.</div><br>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."</blockquote><div><div><br></div><div>From "DNSSEC-bis for complete beginners...":</div><div><br></div></div></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><div><div>- "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."</div></div></div></div><div>- "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."</div></blockquote><div><div><br></div><div>So... I don't quite understand what you mean by:</div><div><br></div><div><blockquote type="cite">using the islands of trust model, _any_ client can trust any keys they choose</blockquote></div><div apple-content-edited="true"><br></div><div apple-content-edited="true">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?</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">- Greg</div><div apple-content-edited="true">

<br>--<br>Please do not email me anything that you are not comfortable also sharing with the NSA.</div></div></body></html>