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

[Ben Schwartz <[e-mail]>]

On Tue, Sep 8, 2020 at 6:05 PM Winfield, Alister <Alister.Winfield=
[e-mail]> wrote:

> That's an interesting use case, and I think it deserves more exposition.
> To me, it raises questions like
>
> * How did the client get configured to use the specified URI template in
> the first place?
>
>
>
> Hopefully some process defined by the working group but right now perhaps
> it’s from an auto-upgrade list in the client.
>

My hope is that we can solve this problem in that process, _before_ the
client receives a DoH URI.  The "auto-upgrade list" is, I believe, a
temporary state of affairs that the ADD process will ultimately resolve.

* Why should the client use the CPE resolver instead of the central
> resolver, if they are administered by the same entity?
>
>
>
> The idea would be that some process as yet undefined gives the URI
> template to the client but assuming we want to be able to change the
> template to support differential services possibly changing with time of
> day eg (malware filtering, no filtering, security monitored etc) plus…
>
>
>
>    1. First mile latency often accounts for >90% of total latency with
>    many home connections so even with a slow CPE cache its faster than going
>    to a central service.
>    2. DoH creates a large connection count issue which you can throw
>    compute and other hardware at to solve but its far easier to reduce it
>    where possible eg reduce the many clients to 1 connection from each CPE to
>    the DoH service. Far easier to scale. To give an idea there is often >10
>    devices per network service if each connects once you have a problem if
>    it’s actually ~5 clients per device then we have to handle x50 connections.
>    A reasonable sized ISP might be worried about supporting 100,000,000’s of
>    stateful connections instead of 1,000,000’s of nearly stateless requests.
>    (likely overestimating but it’s not hard to get to huge numbers if lots of
>    people, devices and clients use DoH)
>    3. If the customer wants it, the CPE resolver can chose different
>    settings on a per-device basis at the CPE. Yes you can configure different
>    URLs in the clients but that’s hard to get customers to do right.
>    Especially if you have to do it to each application separately.
>    4. 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.

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