Re: [dns-privacy] [EXTERNAL] Re: Review request: draft-btw-dprive-rfc8484-clarification

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Please see inline [TR]

From: dns-privacy <[e-mail]> On Behalf Of Ben Schwartz
Sent: Wednesday, September 9, 2020 10:24 PM
To: Neil Cook <neil.cook=[e-mail]>
Cc: Winfield, Alister <[e-mail]>; DNS Privacy Working Group <[e-mail]>
Subject: Re: [dns-privacy] [EXTERNAL] Re: Review request: draft-btw-dprive-rfc8484-clarification



On Wed, Sep 9, 2020 at 11:31 AM Neil Cook <neil.cook=[e-mail]<mailto:[e-mail]>> wrote:



On 9 Sep 2020, at 15:35, Ben Schwartz <bemasc=[e-mail]<mailto:bemasc=[e-mail]>> wrote:


  1.  Caching at the CPE reduces upstream resolver load by quite a lot more than you might imagine not actually a big problem but it’s nice to avoid adding compute if there is a cheaper solution trivially available.
It sounds like the key goal here is caching at the CPE; the other goals could be served by client-specific logic at the central resolver.  Do ISP-provided CPEs normally operate a DNS cache?  My understanding was that they are usually mostly-stateless forwarders.


Yes lots of ISP-provided CPEs do caching. There is a draft in the ADD WG that describes this for at least 3 large ISPs in Europe.

There are other reasons for wanting to do DoH in the CPE, such as performing DNS filtering on the CPE.

This could equally be by client-specific logic on the central resolver, as demonstrated by NextDNS.

BTW I’d interested in how “client-specific logic at the central resolver” solves the connection count issue?

It doesn't, but caching does, hence my conclusion that caching is the focus.
* How does the server know which CPE to redirect the client to?

I’m are assuming here that this is an ISP running both elements so knowing how to map the incoming IP to the name its currently using / was told to use is relatively trivial.

Trivial, perhaps, but not necessarily secure.  An adversary in the network could alter the IP headers to change the apparent client location, causing the client to be redirected to an attacker-controlled CPE, thus defeating the integrity assurances of DoH.

Possible, but I’m not sure this is a practical attack. The attacker would need to be able to also change all the IP headers in the return packets to their original values (that’s hard enough to do for legit purposes).


Sure, but if you assume we don't have a sophisticated active adversary in the network, then we don't need authenticated encryption, and we can solve this without involving the client at all.

[TR] The DNS server hosted on the CPE will only be reachable by endpoints connected to the home network and not accessible to the outside world. If an attacker changes the rules to accept external connections to the DNS server hosted on the CPE managed by the ISP, it can take remediation measures like block internet access to the compromised router or revoke DNS server certificate or block unsolicited incoming traffic to the DNS server on the compromised CPE.

An on-path attacker can change the IP headers but will not succeed establishing encrypted DNS session to the DNS server on the attacker-controlled CPE.

-Tiru

Also, the attacker has to have compromised an ISP-managed CPE, and that CPE still needs to be running on an ISP-managed network connection.

Maybe.  As Alister noted, in some models the subscriber can acquire a DV cert for the name without reaching inside the CPE.


Neil