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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
