<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div apple-content-edited="true"><blockquote type="cite">When one defines all problems to be nails, the solution will always<br>be a hammer, and people making axes will appear to be wasting their<br>time.<br></blockquote><div apple-content-edited="true"><br></div><div apple-content-edited="true">Here, I agree with you.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Where we disagree is in what we consider to be nails, hammers, and axes.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Finding good documentation on DNSSEC has proven to be difficult, but as far as I can tell, DNSSEC appears to be a sort of frankenstein re-implementation of the authentication aspects of SSL/TLS.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">I've yet to see any compelling case that this is not so.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true"><blockquote type="cite">- You're trying to secure HTTP over TLS.</blockquote><br></div><div apple-content-edited="true">Well, duh. That's the bare minimum.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true"><blockquote type="cite">- You assume the destination website has a certificate from a trusted public CA.<br>- You assume that the HTTPS client does not trust any rogue CAs.<br>- You assume that the CA issued the certificate based on criteria stronger<br> than verifying that the requestor seems to control the DNS for the domain.<br>- You assume that CA certificates assert a stronger claim than domain<br> ownership, i.e. some sort of brand validation, as in EV certificates.<br></blockquote></div><div apple-content-edited="true"><blockquote type="cite">- You're only trying to secure the small minority of HTTP sites with EV<br> certificates for brand-name domains.<br></blockquote><div><br></div></div><div apple-content-edited="true">These are all basically the same issue (as far as I can tell), not five separate ones.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">This issue (trust), has not been solved by HTTPS.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">HTTPS does not guarantee trust.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Neither does DNSSEC though! (as far as I can tell)</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">DNSSEC appears to be doing basically the same type of "chain of trust" thing that CA's provide (and in a terribly broken way, I might add).</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">As far as I've been able to understand, it wants a trusted "root":</div><div apple-content-edited="true"><br></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div apple-content-edited="true"><div apple-content-edited="true"><i>"So we need a way
to have trusted keys (anchors) sign further keys, in hopes of one day having a signed root."</i></div></div></blockquote><div apple-content-edited="true"><br></div><div apple-content-edited="true">That's crazy-talk!</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Who wants "a signed root"?!? I don't! Neither should anyone else!</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Haven't we learned from HTTPS that trusting root CAs is a bad idea?</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">DNSSEC doesn't:</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">- encrypt your requests</div><div apple-content-edited="true">- encrypt your data</div><div apple-content-edited="true">- protect you from compromised root keys</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">What good is it?</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Private keys should be treated nonchalantly. If one is compromised, the consequences shouldn't be dire or a pain-in-the-a**. Why? Because private key compromise _will happen_, especially with systems like DNSSEC and HTTPS that put so much importance on them.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">And these guys are seriously trying to coordinate an "international effort" to switch to such a broken system?? Give me a break!</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">I can only hope that the complexity of DNSSEC, and the quarreling over who gets control over the master keys will keep it from ever being adopted or taken seriously.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">The internet is a *<i>NET*work</i>. There is no place on a network for a single point of failure, and any actor burdened with the responsibility of holding "ultimate trust" <b>_automatically_</b> and <b>_necessarily_</b> becomes untrustworthy.</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.<br>
</div>
<br><div><div>On Nov 4, 2013, at 3:55 PM, Viktor Dukhovni <<a href="mailto:cryptography@dukhovni.org">cryptography@dukhovni.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Sun, Nov 03, 2013 at 11:33:37PM -0500, Greg wrote:<br><br><blockquote type="cite">In all my readings on it I kept walking away thinking that I<br>understood its purpose, but I'd then come back at myself with the<br>same question: what does it give us over HTTPS?<br></blockquote><br>Nothing: provided:<br><br>- You're trying to secure HTTP over TLS.<br>- You assume the destination website has a certificate from a trusted public CA.<br>- You assume that the HTTPS client does not trust any rogue CAs.<br>- You assume that the CA issued the certificate based on criteria stronger<br> than verifying that the requestor seems to control the DNS for the domain.<br>- You assume that CA certificates assert a stronger claim than domain<br> ownership, i.e. some sort of brand validation, as in EV certificates.<br>- You're only trying to secure the small minority of HTTP sites with EV<br> certificates for brand-name domains.<br>- If your protocol is not HTTP, there is no DNS-based indirection from<br> client destination to server domain as with MX or SRV records.<br>- ...<br><br>When one defines all problems to be nails, the solution will always<br>be a hammer, and people making axes will appear to be wasting their<br>time.<br><br><blockquote type="cite">What say you list? To me, the DNSSEC thing seems like it might<br>be mostly a waste of a bunch of people's time.<br></blockquote><br>Perhaps the bunch of people "wasting" time on DNSSEC are interested<br>in a broader class of problems.<br><br>-- <br><span class="Apple-tab-span" style="white-space:pre"> </span>Viktor.<br>_______________________________________________<br>The cryptography mailing list<br><a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>http://www.metzdowd.com/mailman/listinfo/cryptography<br></blockquote></div><br></body></html>