[dnssec-deployment] What does DNSSEC enable?
dberger at cs.ucr.edu
Fri Jan 7 11:58:04 EST 2005
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
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
>>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
>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
>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
>Write down, and present to vendors (like Cisco ;-) and let's try to
>convince that it should be implemented.
>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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dnssec-deployment