[Cryptography] DNSSEC = completely unnecessary?

[Greg]

> Check out that _-ANY-_ in the last sentence....

This is a bit too vague for me to understand how it would work in practice. Perhaps the RFC goes into more detail, but I'd rather spend my time on researching less broken systems right now.

Someone sent me a link that led me to this page on DNSSEC failures, and some choice quotes:

http://ianix.com/pub/dnssec-outages.html

Here's two from Moxie (now I know I'm in good company):

"So unfortunately the DNSSEC trust relationships depend on sketchy organizations and governments, just like the current CA system. Worse, far from providing increased trust agility, DNSSEC-based systems actually provide reduced trust agility."
http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

"We had this map of the EFF's SSL Observatory data on what countries are currently capable of intercepting secure communication under the CA system. Under [DNSSEC/DANE], it would look like this."
https://www.youtube.com/watch?v=Z7Wl2FW2TcA#t=33m43s

(He shows a completely red map, indicating all countries)

- Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

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

> 
> every one of those organizations has a vested interest in promoting centralized control 
> of the trust heirarchy.
> 
> http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/dnssec.html
> http://tools.ietf.org/html/rfc5011  -- particularly the Intro.
> 
> As part of the reality of fielding DNSSEC (Domain Name System
>   Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
>   come to the realization that there will not be one signed name space,
>   but rather islands of signed name spaces each originating from
>   specific points (i.e., 'trust points') in the DNS tree.  Each of
>   those islands will be identified by the trust point name, and
>   validated by at least one associated public key.  For the purpose of
>   this document, we'll call the association of that name and a
>   particular key a 'trust anchor'.  A particular trust point can have
>   more than one key designated as a trust anchor.
> 
>   For a DNSSEC-aware resolver to validate information in a DNSSEC
>   protected branch of the hierarchy, it must have knowledge of a trust
>   anchor applicable to that branch.  It may also have more than one
>   trust anchor for any given trust point.  Under current rules, a chain
>   of trust for DNSSEC-protected data that chains its way back to ANY
>   known trust anchor is considered 'secure'.
> 
> ----
> 
> Check out that _-ANY-_ in the last sentence....
> 
> 
> 
> On Tue, Nov 05, 2013 at 01:39:26PM -0500, Greg wrote:
>> 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 bcontrol of the Internetb resides."
>> 
>> - "With DNSSEC, a series of encryption keys are handed off and authenticatedbthe 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 bislands of trustb that rely on intermediate measures to validate their encryption keys.) If the encryption keys donbt 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/9d5e5f37/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/9d5e5f37/attachment.pgp>