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

From: Neil Cook <[email-masked]>
Date: Tue, 8 Sep 2020 12:26:32 +0100

Thanks for reviewing! Some responses inline,

Neil

> On 28 Aug 2020, at 15:41, Ben Schwartz <[email-masked]> wrote:
> 
> Some commentary on this draft:
> 
> Section 3 proposes that there is an apparent inconsistency within RFC 8484 regarding redirection and URI permissioning.  I disagree: I find the meaning of the text in RFC 8484 quite clear and consistent on this point.  To the extent that some aspects of client and server behavior are not specified, this is largely deliberate.  HTTP contains a vast range of behaviors that clients and servers might or might not support, including following of redirects (which is optional [1]).

Well you might find it clear, but before writing the draft the authors exchanged emails with the authors of RFC8484 and even they could not definitively answer the questions we pose in Section 3.

> 
> On server push, I think this draft contains a misunderstanding.  RFC 8484 says that clients must not accept and use DNS records that were pushed from some arbitrary server that is not the client's configured DoH resolver.  (That would obviously be unsafe.)  It does not forbid accepting unsolicited records that were pushed from the configured DoH server.  (In some configurations, unsolicited records of this type would live in a local HTTP cache, invisible to the DNS client layer until a matching query is issued.)
> 

That might be your understanding. It is not universal, hence the need for the clarification.

> The draft contains two proposals that seem to be minimally related.  I would consider splitting them into two drafts.
> 

That is certainly a possibility. Although personally (and this is questioned in the draft itself), I’m not sure that resource-level redirection makes sense given that every unique DNS query could generate a redirect (with caching implications).

> The ".well-known" proposal (Section 6) does what RFC 8484 avoided doing: it proposes an alternative encoding of DNS records in JSON.  As a result, it can only represent a subset of DNS information, with standards work required for each extension.  For example, as currently specified, it cannot represent DNSSEC signatures or the HTTPS RR type.  I would encourage the authors to avoid assumptions about specific RR types, and also to explain why CNAME or Alt-Svc is not sufficient for server changes.

The document goes into detail about why Alt-Svc is not sufficient - the first part of Section 5 as well as Appendix A.
> 
> This proposal seems to assume that there is only one DoH service on the domain that is hosting this JSON file.  This is not required by RFC 8484, and is already false for some major deployments (e.g. NextDNS).
> 

I’m not sure what you mean by this.

> The 3XX proposal (Section 7) sends DNS records in the body of a 3XX response.  This is interesting but definitely unusual: "The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s)." [2].  Also, since following redirects is optional, a server using this mechanism would risk losing any non-redirect-following clients.  That's acceptable if the query would otherwise have to fail, but needs to be mentioned in the draft.
> 

Surely any DoH server returning a 3XX would risk losing any non-redirect-following clients already, regardless of this draft?

> [1] https://tools.ietf.org/html/rfc7231#section-6.4 <https://tools.ietf.org/html/rfc7231#section-6.4>
> [2] https://tools.ietf.org/html/rfc7231#section-6.4.2 <https://tools.ietf.org/html/rfc7231#section-6.4.2>
> On Fri, Aug 28, 2020 at 8:52 AM Brian Haberman <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
>      One of the discussion points during IETF 108 revolved around a
> group of DNS-related drafts without a clear place for discussion. The
> DNSOP, ADD, and DPRIVE chairs and ADs convened a few weeks ago to try
> and sort this out. The upshot of that discussion is that
> draft-btw-dprive-rfc8484-clarification should be discussed on the DPRIVE
> mailing list. So, this is a request for WG participants to review the
> draft and provide feedback on the mailing.
> 
> https://datatracker.ietf.org/doc/draft-btw-dprive-rfc8484-clarification/ <https://datatracker.ietf.org/doc/draft-btw-dprive-rfc8484-clarification/>
> 
> Regards,
> Brian
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>

---

From: Neil Cook <[email-masked]>
Date: Tue, 8 Sep 2020 12:42:56 +0100

> On 31 Aug 2020, at 07:50, Martin Thomson <[email-masked]> wrote:
> 
> I agree with Ben on all points (*) and would prefer to see none of the proposed amendments published.
> 

I think a broader question is necessary in response to this statement. Do you think that  RFC8484 provides enough information for DNS client and servers to implement redirection in an interoperable way? Is redirection necessary? If so do you have any other proposals for how it could be done?

> (*) I think that the push qualification is not necessary, but it is not as clearly a misunderstanding as Ben suggests.  It clearly limits this to configured URIs, which seems in line with original intent.
>  However, it likely denies access to server push in several cases, including after redirects.

I’m not sure it does, however some additional language to extend “configured URIs” to include followed redirects would suffice I imagine.

> 
> On Sat, Aug 29, 2020, at 00:41, Ben Schwartz wrote:
> [...]
>> The ".well-known" proposal (Section 6) does what RFC 8484 avoided 
>> doing: it proposes an alternative encoding of DNS records in JSON.
> 
> I would suggest that authors join the "resolver info" beauty contest.  The use of .well-known rather than (for example) a link relation is clearly inferior for the reasons Ben mentions.  But I tend to think that resource records are more appropriate for this particular application, as they work in more cases.

I understand the concern about encoding RRs; the glue records could be encoded as per a regular DNS response for example. However given that these are glue-style RRs, why would they need to extend beyond A and AAAA? This isn’t a general purpose proposal for encoding DNS records in JSON.

I welcome alternative proposals to using .well-known.

> 
>> The 3XX proposal (Section 7) sends DNS records in the body of a 3XX 
>> response.
> 
> A client that doesn't follow a redirect isn't much use, so the question for me is whether the client gets the extra info it needs.  It seems to me like clients will follow the redirect and discard any content.  That would lead to the extra stuff being dropped.  I would expect a DoH client to make a separate query if it needed more information to follow the redirect.
> 

Doing followup queries is one option, however if that also leads to redirect responses, then there is a major problem.

> A superior design would be to push necessary A/AAAA/CNAME records.  If the client makes a query that ends up at the pushed URI, then this will save time without having to invent novel handling for HTTP messages.
> 

The origin draft actually proposed using server push to push the necessary records. However it was taken out for various reasons, including perceived lack of support for server push in DNS clients.

Neil

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 8 Sep 2020 10:41:03 -0400

On Tue, Sep 8, 2020 at 7:26 AM Neil Cook <[email-masked]> wrote:

> Section 3 proposes that there is an apparent inconsistency within RFC 8484
> regarding redirection and URI permissioning.  I disagree: I find the
> meaning of the text in RFC 8484 quite clear and consistent on this point.
> To the extent that some aspects of client and server behavior are not
> specified, this is largely deliberate.  HTTP contains a vast range of
> behaviors that clients and servers might or might not support, including
> following of redirects (which is optional [1]).
>
>
> Well you might find it clear, but before writing the draft the authors
> exchanged emails with the authors of RFC8484 and even they could not
> definitively answer the questions we pose in Section 3.
>

Of course there are many questions that the draft makes no attempt to
answer, including the question of how best to implement redirection.
However, I do not agree that there is an "apparent inconsistency", as the
authors have previously discussed, e.g.
https://mailarchive.ietf.org/arch/msg/doh/cH_kL3tjtOs-y_ZqRe2iQ5_P4TQ/.

>
> On server push, I think this draft contains a misunderstanding.  RFC 8484
> says that clients must not accept and use DNS records that were pushed from
> some arbitrary server that is not the client's configured DoH resolver.
> (That would obviously be unsafe.)  It does not forbid accepting unsolicited
> records that were pushed from the configured DoH server.  (In some
> configurations, unsolicited records of this type would live in a local HTTP
> cache, invisible to the DNS client layer until a matching query is issued.)
>
>

I'm referring to the line "[RFC8484] does not ... clarify that unsolicited
messages from a configured DoH server should be excluded".  This seems
backwards: the requirement does not exist, so there is nothing to clarify.
In fact, such a requirement would be unimplementable in the cache
architecture that RFC 8484 describes.

...

> I would encourage the authors to avoid assumptions about specific RR
> types, and also to explain why CNAME or Alt-Svc is not sufficient for
> server changes.
>
>
> The document goes into detail about why Alt-Svc is not sufficient - the
> first part of Section 5 as well as Appendix A.
>

This explanation only goes one step, by noting that Alt-Svc requires the
destination to be authoritative for the origin.  The question is: why do
you need to redirect the user to a different origin?  There's a hint about
"redirecting the client to a locally administered DoH server", but I wasn't
able to understand the motivation.  What is the system architecture you are
trying to enable, and why?

>
> This proposal seems to assume that there is only one DoH service on the
> domain that is hosting this JSON file.  This is not required by RFC 8484,
> and is already false for some major deployments (e.g. NextDNS).
>
>

DoH URIs are full URIs, not merely domain names, so there can be an
unlimited number of DoH servers on a single domain, at different paths,
with different behaviors.  An example of an existing domain with this
behavior is dns.nextdns.io, which has one such DoH path for every user.
The proposed .well-known structure does not appear to support this
configuration: it would collapse all these disparate paths onto a single
destination template.

> response.  This is interesting but definitely unusual: "The server's
> response payload usually contains a short hypertext note with a hyperlink
> to the new URI(s)." [2].  Also, since following redirects is optional, a
> server using this mechanism would risk losing any non-redirect-following
> clients.  That's acceptable if the query would otherwise have to fail, but
> needs to be mentioned in the draft.
>
>
> Surely any DoH server returning a 3XX would risk losing any
> non-redirect-following clients already, regardless of this draft?
>

Yes, but the draft is encouraging servers to do this, so it needs a warning
label.

On Tue, Sep 8, 2020 at 7:43 AM Neil Cook <neil.cook=
[email-masked]> wrote:

> Do you think that  RFC8484 provides enough information for DNS client and
> servers to implement redirection in an interoperable way?

Yes, insofar as it "might" work, which is all that can be said, since
redirection itself is optional.

Is redirection necessary?

I'm not aware of an important use case for redirection.

> If so do you have any other proposals for how it could be done?
>

Servers can redirect any query except those needed to follow the redirect.

...

> I understand the concern about encoding RRs; the glue records could be
> encoded as per a regular DNS response for example. However given that these
> are glue-style RRs, why would they need to extend beyond A and AAAA? This
> isn’t a general purpose proposal for encoding DNS records in JSON.
>

As I noted, your proposal already breaks client-side DNSSEC validation, and
would prevent use of the new HTTPS RR.  The set of "glue-style" RRs that
might be needed here is evolving, and may continue to evolve.

---

From: Neil Cook <[email-masked]>
Date: Tue, 8 Sep 2020 16:32:57 +0100

> On 8 Sep 2020, at 15:41, Ben Schwartz <[email-masked]> wrote:
> 
> Of course there are many questions that the draft makes no attempt to answer, including the question of how best to implement redirection.

I’m not sure how to take the above statement. The draft explicitly tries to answer how to best implement redirection.

> However, I do not agree that there is an "apparent inconsistency", as the authors have previously discussed, e.g. https://mailarchive.ietf.org/arch/msg/doh/cH_kL3tjtOs-y_ZqRe2iQ5_P4TQ/ <https://mailarchive.ietf.org/arch/msg/doh/cH_kL3tjtOs-y_ZqRe2iQ5_P4TQ/>.

From that email thread:

On Mar 31, 2020, at 2:03 AM, [email-masked] <mailto:[email-masked]> wrote:
> I'm now more puzzled about the intent of the document with regards to redirection:

That's fine, and you are not alone. But the proper resolution of that puzzlement is not an erratum, it is a document update.

--Paul Hoffman

> I'm referring to the line "[RFC8484] does not ... clarify that unsolicited messages from a configured DoH server should be excluded".  This seems backwards: the requirement does not exist, so there is nothing to clarify.  In fact, such a requirement would be unimplementable in the cache architecture that RFC 8484 describes.
> 

Actually that is a bug. It should say “not be excluded”.

> ...
>> I would encourage the authors to avoid assumptions about specific RR types, and also to explain why CNAME or Alt-Svc is not sufficient for server changes.
> 
> This explanation only goes one step, by noting that Alt-Svc requires the destination to be authoritative for the origin. 

It also explains that Alt-Svc suffers from the bootstrapping problem, which is discussed in multiple places in the draft.

> The question is: why do you need to redirect the user to a different origin?  There's a hint about "redirecting the client to a locally administered DoH server", but I wasn't able to understand the motivation.  What is the system architecture you are trying to enable, and why?

One of the original motivations was to enable redirection from a central DoH server to a DoH forwarder running on e.g. a home router (in this case managed and provided by the operator of the central DoH server). Thus you might start off talking to “https://example.com/whatever <https://example.com/whatever>” and you would be redirected to “https://cpe1234.example.com/whatever <https://cpe1234.example.com/whatever>”. That’s why this draft was in the ADD WG before dprive.

> DoH URIs are full URIs, not merely domain names, so there can be an unlimited number of DoH servers on a single domain, at different paths, with different behaviors.  An example of an existing domain with this behavior is dns.nextdns.io <http://dns.nextdns.io/>, which has one such DoH path for every user.  The proposed .well-known structure does not appear to support this configuration: it would collapse all these disparate paths onto a single destination template.

Yeah understood. 

> Yes, but the draft is encouraging servers to do this, so it needs a warning label.
>  
> On Tue, Sep 8, 2020 at 7:43 AM Neil Cook <neil.cook=[email-masked] <mailto:[email-masked]>> wrote:
> Do you think that  RFC8484 provides enough information for DNS client and servers to implement redirection in an interoperable way?
> 
> Yes, insofar as it "might" work, which is all that can be said, since redirection itself is optional.

It “might" work isn’t enough to develop clients and servers that interoperate. 

HTTP redirects are not designed for the situation where the redirect requires DNS to function, but the DNS server itself is the service returning the redirect.

If a redirection response is received by a DoH client, should it:
a) Lookup the required DNS records using the same DoH server? What if they lead to further redirect responses?
b) Fallback to unencrypted DNS?
c) Something else?

RFC8484 says nothing on the above, hence the motivation for this draft.

> I'm not aware of an important use case for redirection.

If nobody in this WG is convinced that DoH redirection is important enough to work on, then that’s fine. But if this WG think that it’s important, then RFC8484 is not enough IMO.

> Servers can redirect any query except those needed to follow the redirect.

I’m not sure if that could be easily implementable in a DNS server (the redirect might lead to a long chain of CNAMEs for example, and the server would need to maintain state across queries), but I’d be interested to see if it could be. If so, it would certainly be a more attractive approach.

> As I noted, your proposal already breaks client-side DNSSEC validation, and would prevent use of the new HTTPS RR.  The set of "glue-style" RRs that might be needed here is evolving, and may continue to evolve.

Sure, so using standard DNS encoding would address that.

Neil

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 8 Sep 2020 15:31:32 -0400

On Tue, Sep 8, 2020 at 11:33 AM Neil Cook <[email-masked]> wrote:

> I’m not sure how to take the above statement. The draft explicitly tries
> to answer how to best implement redirection.
>

I was unclear; I was referring to RFC 8484.

...

> The question is: why do you need to redirect the user to a different
> origin?  There's a hint about "redirecting the client to a locally
> administered DoH server", but I wasn't able to understand the motivation.
> What is the system architecture you are trying to enable, and why?
>
>
> One of the original motivations was to enable redirection from a central
> DoH server to a DoH forwarder running on e.g. a home router (in this case
> managed and provided by the operator of the central DoH server). Thus you
> might start off talking to “https://example.com/whatever” and you would
> be redirected to “https://cpe1234.example.com/whatever”. That’s why this
> draft was in the ADD WG before dprive.
>

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?
* Why should the client use the CPE resolver instead of the central
resolver, if they are administered by the same entity?
* How does the server know which CPE to redirect the client to?
* What are the trust properties of a certificate stored on the CPE?
* Could you use IP certificates to avoid the bootstrap problem?

There are numerous potential ways to enable encryption between the client
and CPE; it's not at all obvious to me that the right solution is to
integrate with DoH in this way.

> It “might" work isn’t enough to develop clients and servers that

Sure.  To be precise, RFC 8484 imposes enough requirements on clients that
a server can implement redirection in a way that works for at least some
use cases, for all RFC8484 clients that also support redirection.

...

> I’m not sure if that could be easily implementable in a DNS server (the
> redirect might lead to a long chain of CNAMEs for example, and the server
> would need to maintain state across queries), but I’d be interested to see
> if it could be. If so, it would certainly be a more attractive approach.
>

You could also use static analysis to avoid keeping state across
queries, if the destination domain is cooperating (as in your example
above).  That said, this is all much simpler and more performant if the
goal is only to redirect some small category of queries, as opposed to
redirecting everything.  That goes back to the question of use cases.

---

From: "Winfield, Alister" <[email-masked]>
Date: Tue, 8 Sep 2020 22:05:01 +0000

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.

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

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.

You got me ! This is the one thing that has me staring hard at a sheet of paper full of crossed out ideas. One mistake and you might as well run over an unencrypted connection. Getting a signed certificate is easy. Ensuring no-one connected to the CPE can’t get a certificate for the same name is somewhat of a challenge. Avoiding storing such a cert and key on the flash is possible with some provisioning action at connection time.

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

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 9 Sep 2020 10:35:33 -0400

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

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

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

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

---

From: "Winfield, Alister" <[email-masked]>
Date: Wed, 9 Sep 2020 15:24:27 +0000

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=[email-masked]>
Date: Wednesday, 9 September 2020 at 15:36
To: "Winfield, Alister" <[email-masked]>
Cc: Neil Cook <[email-masked]>, DNS Privacy Working Group <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> 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?

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.

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.

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.

---

From: Neil Cook <[email-masked]>
Date: Wed, 9 Sep 2020 16:31:18 +0100

> On 9 Sep 2020, at 15:35, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 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.

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.

BTW I’d interested in how “client-specific logic at the central resolver” solves the connection count issue?
> 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-cont…

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

Neil

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 9 Sep 2020 12:53:53 -0400

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

>>    1. Caching at the CPE reduces upstream resolver load by quite a lot
> 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.
>

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.

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

---

From: Neil Cook <[email-masked]>
Date: Thu, 10 Sep 2020 12:09:38 +0100

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

> 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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 11 Sep 2020 05:39:53 +0000

Please see inline [TR]

From: dns-privacy <[email-masked]> On Behalf Of Ben Schwartz
Sent: Wednesday, September 9, 2020 10:24 PM
To: Neil Cook <neil.cook=[email-masked]>
Cc: Winfield, Alister <[email-masked]>; DNS Privacy Working Group <[email-masked]>
Subject: Re: [dns-privacy] [EXTERNAL] Re: Review request: draft-btw-dprive-rfc8484-clarification

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

On 9 Sep 2020, at 15:35, Ben Schwartz <bemasc=[email-masked]<mailto:bemasc=[email-masked]>> 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.

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.

-Tiru

Neil

---

From: Rob Sayre <[email-masked]>
Date: Thu, 10 Sep 2020 22:51:10 -0700

> This could equally be by client-specific logic on the central resolver, as

Well, the encryption is going to happen, and it will usually bypass the
CPE. That will upset some parties.

See you later (unsubscribing),
Rob

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 11 Sep 2020 10:46:43 -0400

On Fri, Sep 11, 2020 at 1:40 AM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:
...

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

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.

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 14 Sep 2020 05:59:19 +0000

Hi Ben,

Please see inline

From: Ben Schwartz <[email-masked]>
Sent: Friday, September 11, 2020 8:17 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Neil Cook <[email-masked]>; Winfield, Alister <[email-masked]>; DNS Privacy Working Group <[email-masked]>
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-masked]<mailto:[email-masked]>> wrote:
...
* How does the server know which CPE to redirect the client to?

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

Neil