Re: [dns-privacy] [SPAM] Re: New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

[Andrew Sullivan <[e-mail]>]

On Wed, Aug 20, 2014 at 03:38:41PM +0000, Hosnieh Rafiee wrote:
> 
> So in long term there is no benefit to use encryption without authentication in resolver scenario.  

Let us be concrete.  There are four cases:

1.  A stub that connects to whatever resolver it gets by magic from
DHCP.  

2.  A stub that connects to a specific resolver on the same network as
itself.  This is like your ISP's resolver, when you specifically
configure the resolver.  

3.  A stub that connects to a specific resolver over the public
Internet.  This is like using Google's public DNS service.

4.  A full-service resolver.

In (1), othing can help, because DHCP is kind of trivial to subvert,
so you could be talking to anything.  In (2), your arguments sort of
work, because the attack is localized attempting to snarf _particular_
traffic.  In (3), however, your arguments don't work: the threat is
not actually to particular traffic, but to _all_ traffic; and any
attack that would actually depend on spoofing addresses or the like
would be observable by the service provider, which foils the attack.
In (4), of course, we don't have the problem.  I include it because
the validating stub in effect ends up having to chase most things
itself, so it devolves to this.

Your argument works if one is trying to prevent someone getting
particular traffic.  If the threat, however, is the general snarfing
up of all the traffic towards a particular resolver with the goal of
learning about all of its traffic, then even if some of it leaks
that's not a big deal.  In this case, failing to authenticate the
resolver presents no real additional vulnerability.

Best regards,
 
A
-- 
Andrew Sullivan
[e-mail]