Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Doug Barton <[e-mail]>]

On 08/19/2018 06:18 AM, Livingood, Jason wrote:
> So I suppose that the threat model in this example is presumably someone (1) eavesdropping on the relatively short path between CMTS and resolver or (2) modifying non-DNSSEC-validated responses - and that's does not seem like a very high risk threat IMO, given all the other potential and real threats lurking around on the Internet.

Personally I see securing the path from the stub to the resolver as a 
good step in the ultimate goal of encrypting all of the things. :) I'd 
like to see the traffic from the resolver to the authorities encrypted 
as well, along with all the other traffic on the Internet.

In years past people like me who pushed "encrypt, encrypt, encrypt!" 
were seen as kooks, but we now know beyond a shadow of a doubt that 
there are a legion of organizations, both public and private sector, 
that are collecting every piece of data about every person that they 
can. We also know that their reach is way farther than was imagined, and 
it's probably actually farther than what we know now.

So the question isn't, "Why encrypt?" the question is, why on earth 
wouldn't you want to?

And Jason, you missed a threat model, which is users who want to bypass 
their ISP's resolver.

I agree that encrypting from the CMTS to the local resolver isn't that 
valuable, since (unless I'm missing something) the ISP is the only one 
that can see that traffic, and they'll be able to log/manipulate the 
resolver already. So it's unlikely that an ISP would deploy DOH or DOT 
in the first place, so the idea of a DHCP option to support it isn't 
necessarily relevant in that environment. That doesn't mean it's not 
relevant elsewhere.

Doug