Hi Ben,

Please see inline

From: Ben Schwartz <[email protected]>
Sent: Friday, September 11, 2020 8:17 PM
To: Konda, Tirumaleswar Reddy <[email protected]>
Cc: Neil Cook <[email protected]>; Winfield, Alister 
<[email protected]>; DNS Privacy Working Group <[email protected]>
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 
<[email protected]<mailto:[email protected]>> 
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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to