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

["Winfield, Alister" <[e-mail]>]

Yep never said it was a great idea once you hit the security issues. The upsides are tempting but the piece of paper with scribbled diagrams on it hasn’t got a complexly secured answer as of yet.

Best solution I have is to talk CPE vendors into having a small HSM like device in there so they can answer as if they are the public DNS service keeping the secrets secured against attackers. This, however, is a multi-year (>5) type solution so not useful in the short term and potentially not viable for other business reasons.

A.


From: Ben Schwartz <bemasc=[e-mail]>
Date: Wednesday, 9 September 2020 at 15:36
To: "Winfield, Alister" <[e-mail]>
Cc: Neil Cook <[e-mail]>, DNS Privacy Working Group <[e-mail]>
Subject: Re: [EXTERNAL] Re: [dns-privacy] Review request: draft-btw-dprive-rfc8484-clarification

On Tue, Sep 8, 2020 at 6:05 PM Winfield, Alister <Alister.Winfield=[e-mail]<mailto:[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.

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD