Re: [perpass] DNS confidentiality

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Sep 25, 2013 at 3:59 PM, Stephen Farrell
<[e-mail]>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/