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

[Neil Cook <[e-mail]>]

> On 9 Sep 2020, at 17:53, Ben Schwartz <[e-mail]> wrote:
> 
> 
> 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.
> 

Agreed, and it’s being done by many folks, not just NextDNS (all large UK ISPs have had the capability do this for over 5 years, and it’s used by millions of consumers).

> 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.

I’m not sure I follow. The CPE could do no caching, and the central resolver would still benefit from the decreased connection count, just not a decreased query load.

> 
> 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.

I think these are notional models - I’m not aware of any CPEs supporting a DoH forwarder currently. Certainly if it were to be done, securing the keying material would be extremely important.

Neil