[dnssec-deployment] What does DNSSEC enable?

[Dan Berger]

Shameless plug - two colleagues and I have done some work in proposing 
and prototyping a key distribution scheme that layers on DNSSEC using 
DNS domains and DNSSEC trust chains.  We submitted the work to USENIX 
'05, but it was rejected - the reviewers had a hard time deciding if it 
was a "crypto" or a "systems" paper.  If anyone here would be interested 
in reviewing a revised draft or technical report, please drop me a note 
off-list. 

Cheers.

Patrik Fältström wrote:

>On Jan 7, 2005, at 03:47, James M Galvin wrote:
>
>  
>
>>Steve Crocker noted that what we need to, at least in part, is create
>>the right balance between DNSSEC securing DNS and DNSSEC enable new
>>"things".
>>
>>Allison Mankin suggested that using the DNS as a trust anchor is
>>probably a concept that could be leveraged by applications.  We should
>>engage browser vendors so we can better understand what they want and
>>need.
>>    
>>
>
>I think Allison is on the right track here.
>
>The key thing with DNSSEC is that we already have a chain of trust in 
>the DNS hierarchy. This independent of whether people complain on 
>ICANN, DoC or not. There is a root zone. There is a strict hierarchy of 
>delegations. There is a process to follow when delegating from one 
>domain to another (you only delegate administrative rights, you don't 
>give away responsibility).
>
>For TLS/SSL the trust chain is from the end user via the browser 
>vendors to the CA's that "pay enough". I use quotation marks here 
>because I don't know exactly what the selection process is for example 
>inside Netscape or Microsoft when they select CA certs to be included 
>in their browsers.
>
>What *WE* know is that very few people, if any, is verifying whether 
>the browser they have installed actually has not changed since the 
>master was loaded with certs. I also know that at least around 1998, no 
>browser was checking whether a cert in the CA cert chain was changed 
>with a simple editor. I.e. the cert still was claimed to be from for 
>example Verisign, but the content of the cert had changed to be some 
>bogus thing. An operation a trojan could do very easily.
>
>I claim the chain of trust we have with TLS/SSL is very weak.
>
>At the same time, what TLS/SSL in reality do (with the padlock image) 
>is to say whether the communication is encrypted and protected from 
>wiretapping. This more than "you have connected to the correct site". 
>I.e. in Applications Area in the IETF, we try to tell people TLS/SSL is 
>for securing the communication, and that authentication of the parties 
>is something one can do on top of SSL/TLS (and easy to do if you know 
>the connection is secure).
>
>Given this, what is DNSSEC helping with?
>
>As Allison said, it is a very good bootstrapping mechanism as we 
>already do trust DNS. We do trust the delegation chain, and the chain 
>is secured using DNSSEC. By storing things in specific zones in DNS, we 
>will have trust all the way from the anchor down to the record we want. 
>On top of that, the record itself is signed, which imply we can trust 
>the RDATA in it.
>
>The record we look for can include of course the IP address of 
>something, but honestly, the routing system can be attacked as well, so 
>what does this help with? We probably need SSL+authentication anyways 
>if only A records are what we get, so for this, I agree with Jon 
>Peterson that in the browser world, it doesn't add much. It doesn't add 
>much because we have so many other attacks possible. (I don't even 
>start talking about the problems with HTML, frames, XML etc.)
>
>Interesting records are instead NAPTR and special records that give 
>back keys for other security mechanisms. Like whatever is needed for 
>PGP, IPSEC tunnels, TLS certs (yes, instead of the browser CA certs), 
>SSH certs etc.
>
>Because of this, I think use of DNSSEC is for (boring) security 
>mechanisms that don't have any good bootstrapping mechanism yet. Or, 
>for applications that do need security. That end users that are not 
>geeks think should be "very secure". Like VoIP (I now think of ENUM, 
>securing the mapping between an E.164 and a SIP address in the NAPTR 
>record).
>
>One more question is "who should pay for implementation of DNSSEC in 
>the application". Code is needed. Coding is needed. Who should do it, 
>and why? Who pays?
>
>This is where I think browser vendors will be hard to convince. The 
>application is cool, and it reaches many users. But why?
>
>Only path forward for browsers is, I think, that the people that 
>implement DNSSEC (i.e. "we") also hack the open source projects like 
>Mozilla so the right (another?) icon is display beside the padlock. I 
>think it would be very hard to get the browser hackers to do it. They 
>have enough problems getting CSS, Java and what not to work.
>
>But we have other applications as well, and we should find more precise 
>technical descriptions for them. How to bootstrap SSH security from 
>trust in DNSSEC? How to bootstrap IPSEC security from trust in DNSSEC? 
>I know Jacob Schlyter have made some tries with appkey RR type and 
>later more specific RR types.
>
>A very cool application is, I think, the mix between DNS Dynamic 
>Updates (secured via SIG(0)), DNSSEC and IPSEC tunnels between devices 
>that move around (or get IP addresses in large networks from ISP's via 
>DHCP).
>
>Write down, and present to vendors (like Cisco ;-) and let's try to 
>convince that it should be implemented.
>
>     paf
>
>#############################################################
>This message is sent to you because you are subscribed to
>  the mailing list <dnssec-deployment at shinkuro.com>.
>To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
>To switch to the DIGEST mode, E-mail to <dnssec-deployment-digest at shinkuro.com>
>To switch to the INDEX mode, E-mail to <dnssec-deployment-index at shinkuro.com>
>Send administrative queries to  <dnssec-deployment-request at shinkuro.com>
>
>  
>

-- 

...Dan Berger [dberger at cs.ucr.edu]
   Department of Computer Science
   University of California, Riverside
   http://www.cs.ucr.edu/~dberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20050107/c389714f/attachment.html