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

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

Hi Ben,

Please see inline

From: Ben Schwartz <[e-mail]>
Sent: Friday, September 11, 2020 8:17 PM
To: Konda, Tirumaleswar Reddy <[e-mail]>
Cc: Neil Cook <[e-mail]>; Winfield, Alister <[e-mail]>; DNS Privacy Working Group <[e-mail]>
Subject: Re: [dns-privacy] [EXTERNAL] Re: Review request: draft-btw-dprive-rfc8484-clarification



On Fri, Sep 11, 2020 at 1:40 AM Konda, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>> wrote:
...
* 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.

An on-path attacker could be inside the victim's home network, rerouting the victim's connections into the attacker's network.

[TR2] I think you are referring to an internal attacker acting as an on-path attacker setting up a tunnel to the attacker's network to discover the DoH server on the attacker-controlled CPE (similar to VPN on from branch/virtual office to HQ). This attack looks expensive and possibility can be detected by TOFU (assuming attacker will not be always be on-path).

My broader point is that the proposed architecture requires a weaker threat model than the one used by HTTPS (and therefore DoH).  We should consider that threat model carefully before selecting a solution.  A weaker threat model can be a good thing: it may mean that there is a much easier solution.

[TR2] Agreed.

Cheers,
-Tiru


-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