On Wed, Sep 25, 2013 at 3:59 PM, Stephen Farrell <[email protected]>wrote:
> > Hi Paul, > > On 09/25/2013 08:34 PM, Paul Wouters wrote: > > > > What we don't need though is another dns-like protocol to do so. (and > > definitely not dnscurve, as it does not support dns data authenticity, > > only transport security) > > You might be right about dnscurve, or maybe not. I dunno > enough about it yet to be to be honest. But, as you know, > DNSSEC is where the IETF has placed its bet for DNS data > origin auth. +1 I really can't see how DNSCurve would have been practical if it had a clear field. But now that we have bet on DNSSEC for authenticating the data within a DNS zone, that is a fixed choice. We can change some of the offensive parts of the DNSSEC architecture like the fact that it grants ICANN entire control over who is in the DNS and who is not. There is no reason that ICANN should have the ability to drop Cuba or Iran out of the root when Ted Cruz is threatening to filibuster the deficit ceiling limit rise if the President won't sign a bill forcing the US corporation to do that. > Changing that would maybe require a seismic > shift, so for this discussion I was assuming DNSSEC is the > answer for data origin auth and just asking if it'd be > useful to add confidentiality. So, the fact that dnscurve > doesn't do what DNSSEC does isn't really a compelling > argument here I think. > What we want from a design point of view is a secure mechanism for securing the channel based on a long term session key. One option for that would be DTLS. But since all we are doing is signing and encrypting packets under a long term session key we can achieve the desired end with a much simpler Kerberos-like scheme. DTLS is actually a poor choice here because TLS is designed on the assumption that the DNS layer stuff has already taken place. It uses certificate chains and PKIX infrastructure that layers over TCP/IP and DNS. > Cheers, > S. > > PS: Yes, we should all be doing stuff to encourage more > deployment of DNSSEC, but I think that's a separate > discussion, for other lists probably, even though DNSSEC > deployment might make it harder to mount some attacks > that are used in monitoring. A replacement for the client-resolver protocol is one of the steps I think would best help deployment of DNSSEC. That is where much of the difficulty in making schemes like DANE practical lies. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
