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

[Ben Schwartz <[e-mail]>]

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

>
>
> On 9 Sep 2020, at 15:35, Ben Schwartz <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.

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
>