Subject: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

From: Andrew Campling <[email-masked]>
Date: Wed, 15 Jul 2020 16:59:57 +0000

ADD and EDDI Groups
This is to let you know that a new I-D has been submitted for consideration by the ADD WG that includes observations regarding a variety of implementations of recursive DNS capabilities that are important to network operators in terms of delivering DNS services to their customers.  The document defines problems that need technical solutions to allow the deployment of encrypted DNS by the largest number of operators to the largest number of users in the shortest possible timeframe with little or no disruption to the user experience, ideally by clients using the "same provider auto-upgrade" approach wherever possible.

      Name:             draft-campling-operator-observations
      Revision: 00
      Title:            Practical Observations from Encrypted DNS Deployments by Network Operators
      Document date:    2020-07-13
      Group:            Individual Submission
      Pages:            9
      URL:              https://www.ietf.org/internet-drafts/draft-campling-operator-observations-00.txt
      Status:           https://datatracker.ietf.org/doc/draft-campling-operator-observations/
      Htmlized:         https://tools.ietf.org/html/draft-campling-operator-observations-00
      Htmlized:         https://datatracker.ietf.org/doc/html/draft-campling-operator-observations

We hope that the details in this document will aid the development of discovery mechanisms for DNS resolvers including those using DoH.  Discussion of its content is encouraged on the IETF ADD mailing list [email-masked]<mailto:[email-masked]>, especially concerning any contributions from additional network operators to make the content as fully representative as possible of the significant use cases globally.

Andrew, Normen, Gianpaolo, Chris, Alister

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 16 Jul 2020 09:12:19 +1000

Hi Andrew,

Your draft seems to be making a case for supporting forwarders, but I'm not clear on what supporting forwarders looks like.  I understand that you might not have specific ideas about what this support might look like, but I don't see any real requirements here either.

It would really help if the draft would clearly articulate what your desired outcome is.

I note that SPAU - as described - only really operates when the forwarder has been cut out already.  I don't believe that there are many CPE devices that intercept traffic on UDP port 53 to do their work, but it isn't unthinkable.  If there are, those are the only ones truly affected by the described upgrade to encrypted transport.

There is a SPAU upgrade path that might concern you more:

Query using the default resolver for a name where the LHS labels are unique (and therefore unlikely to be cached anywhere) and the RHS labels identifies a zone under the control of the entity making the probe.  The authoritative puts the IP of the resolver that made the call in the answer.  This probably won't be a recognizable address for the resolver, and it almost certainly won't be a quad-N anycast address, but it will identify the true resolver with fair accuracy.  The client can then do a lookup and upgrade, cutting out any forwarder.  (A variation on this has the authoritative perform the lookup, which might be superior from a deployment perspective as it centralizes the lookup tables.)

Cheers,
Martin

On Thu, Jul 16, 2020, at 02:59, Andrew Campling wrote:
>  
> *ADD **and EDDI **Group**s*
> This is to let you know that a new I-D has been submitted for 
> consideration by the ADD WG that includes observations regarding a 
> variety of implementations of recursive DNS capabilities that are 
> important to network operators in terms of delivering DNS services to 
> their customers.  The document defines problems that need technical 
> solutions to allow the deployment of encrypted DNS by the largest 
> number of operators to the largest number of users in the shortest 
> possible timeframe with little or no disruption to the user experience, 
> ideally by clients using the “same provider auto-upgrade” approach 
> wherever possible.
>  
> URL:             
> _https://www.ietf.org/internet-drafts/draft-campling-operator-observations-00.txt_
> Status:          
> _https://datatracker.ietf.org/doc/draft-campling-operator-observations/_
> Htmlized:        
> _https://tools.ietf.org/html/draft-campling-operator-observations-00_
> Htmlized:        
> _https://datatracker.ietf.org/doc/html/draft-campling-operator-observations_
>  
> We hope that the details in this document will aid the development of 
> discovery mechanisms for DNS resolvers including those using DoH.  
> Discussion of its content is encouraged on the IETF ADD mailing list 
> [email-masked], especially concerning any contributions from additional 
> network operators to make the content as fully representative as 
> possible of the significant use cases globally.  
>  
>  
> *Andrew**, Normen, G**ianpaolo, Chris, Alister *
>  
>  
>  
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 17 Jul 2020 10:37:53 +0200 (CEST)

> Il 16/07/2020 01:12 Martin Thomson <[email-masked]> ha scritto:
> 
>  
> Hi Andrew,
> 
> Your draft seems to be making a case for supporting forwarders, but I'm not clear on what supporting forwarders looks like. 

Possibly you should have a look at the companion draft:

https://datatracker.ietf.org/doc/draft-cook-doh-discovery-trial/?include_text=1

It is a report about a possible trial that a set of ISPs would like to do. The mechanism is not so different from draft-resinfo (and could be brought in line with it) but it builds on the idea of pre-vetted lists of resolvers in browsers for additional security. It is meant to be immediately deployable as an opportunistic gain in security for ISP customers in Europe, and as an incentive for ISPs to deploy DoH, while something more general gets developed here.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: tirumal reddy <[email-masked]>
Date: Fri, 17 Jul 2020 20:23:39 +0530

Hi Martin,

Nowadays home routers are capable of running network security services. For
example, DNS filtering to enforce MUD
(https://tools.ietf.org/html/rfc8520) rules
for IoT devices, blocking malware/phishing sites, parental control, anomaly
detection etc.

SPAU allows the ISP DoH/DoT resolver to enforce DNS filtering for the
entire home but cannot enforce device level filtering, isolate infected
devices, identify local attacks etc.

Cheers,
-Tiru

On Thu, 16 Jul 2020 at 04:42, Martin Thomson <[email-masked]> wrote:

> Hi Andrew,
>
> Your draft seems to be making a case for supporting forwarders, but I'm
> not clear on what supporting forwarders looks like.  I understand that you
> might not have specific ideas about what this support might look like, but
> I don't see any real requirements here either.
>
> I note that SPAU - as described - only really operates when the forwarder
> has been cut out already.  I don't believe that there are many CPE devices
> that intercept traffic on UDP port 53 to do their work, but it isn't
> unthinkable.  If there are, those are the only ones truly affected by the
> described upgrade to encrypted transport.
>
> Query using the default resolver for a name where the LHS labels are
> unique (and therefore unlikely to be cached anywhere) and the RHS labels
> identifies a zone under the control of the entity making the probe.  The
> authoritative puts the IP of the resolver that made the call in the
> answer.  This probably won't be a recognizable address for the resolver,
> and it almost certainly won't be a quad-N anycast address, but it will
> identify the true resolver with fair accuracy.  The client can then do a
> lookup and upgrade, cutting out any forwarder.  (A variation on this has
> the authoritative perform the lookup, which might be superior from a
> deployment perspective as it centralizes the lookup tables.)
>
> Cheers,
> Martin
>
>
> > _
> https://www.ietf.org/internet-drafts/draft-campling-operator-observations-00.txt_
> > Status:
> > _
> https://datatracker.ietf.org/doc/html/draft-campling-operator-observations_
> >

---

From: Kenji Baheux <[email-masked]>
Date: Mon, 20 Jul 2020 09:26:54 +0900

I'd like to get a clear picture of how per-device family-safe filtering is
typically configured in a plain ISP setup.

I imagine that the ISP provided router offers a UI through which a parent
(logged in user) could add/remove specific devices to the "family-safe:
enabled" list.

Which information is being used to dissociate the  devices?
What does the router do differently from there on? Where does the filtering
actually occur, on the upstream resolver (different one?)?

Thanks.

On Fri, Jul 17, 2020 at 11:54 PM tirumal reddy <[email-masked]> wrote:

> Hi Martin,
>
> Nowadays home routers are capable of running network security services.
> For example, DNS filtering to enforce MUD (
> https://tools.ietf.org/html/rfc8520) rules for IoT devices, blocking
> malware/phishing sites, parental control, anomaly detection etc.
>
>> https://datatracker.ietf.org/doc/draft-campling-operator-observations/_
>> > Htmlized:
>> https://datatracker..ietf.org/doc/html/draft-campling-operator-observations_
>> <https://datatracker.ietf.org/doc/html/draft-campling-operator-observations_>
>> >

-- 
Kenji BAHEUX
Product Manager - Chrome
Google Japan

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 20 Jul 2020 10:32:50 +1000

Hi Tiru,

I should remind you of the difference between describing a mechanism (as Vittorio did) and advocating for a particular policy regime.  This message appears to be the latter and therefore out of scope for this group.  If you want to continue that discussion, we're discussing https://tools.ietf.org/html/draft-thomson-tmi-00 on the [email-masked] list.

On Sat, Jul 18, 2020, at 00:53, tirumal reddy wrote:
> For example, DNS filtering to enforce MUD 
> (https://tools.ietf.org/html/rfc8520) rules for IoT devices, blocking

---

From: tirumal reddy <[email-masked]>
Date: Mon, 20 Jul 2020 13:48:08 +0530

> (logged in user) could add/remove specific devices to the "family-safe:

Yes.

> Which information is being used to dissociate the  devices?

The UI typically displays the device type, make, model, MAC address and IP
addresses. The per-device specific policy is enforced using the MAC address.

> What does the router do differently from there on? Where does the
> filtering actually occur, on the upstream resolver (different one?)?
>

The DNS filtering can either happen in the DNS forwarder in the home router
or enforced by the ISP DNS recursive server.

Cheers,
-Tiru

>>> I note that SPAU - as described - only really operates when the
>>> forwarder has been cut out already.  I don't believe that there are many
>>> CPE devices that intercept traffic on UDP port 53 to do their work, but it
>>> isn't unthinkable.  If there are, those are the only ones truly affected by
>>> the described upgrade to encrypted transport.
>>>

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 20 Jul 2020 10:53:54 +0200 (CEST)

>     Il 20/07/2020 02:26 Kenji Baheux <kenjibaheux=[email-masked]> ha scritto:
>      
>      
>     I'd like to get a clear picture of how per-device family-safe filtering is typically configured in a plain ISP setup.
>      
>     I imagine that the ISP provided router offers a UI through which a parent (logged in user) could add/remove specific devices to the "family-safe: enabled" list.
> 
It depends on the implementation. In other cases, the filtering engine and the UI reside on the ISP's central resolver platform, and the CPE only adds an identifier (which can be generated locally and opaque) that allows the platform to tell which device is sending the query.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: tirumal reddy <[email-masked]>
Date: Mon, 20 Jul 2020 15:11:30 +0530

Hi Martin,

Thanks for the pointer. My intent is to say nowadays home routers are
capable of running network security services and can easily be upgraded
with new firmware and configuration. These home routers can run DoH/DoT
forwarder. https://tools.ietf.org/html/draft-btw-add-home-07#section-
<https://tools.ietf.org/html/draft-btw-add-home-06#section-7>7 discusses
hosting the DoH/DoT forwarder on the home router and how the client can
discover the local DoH/DoT server (with and without SPAU).

Legacy routers that cannot be upgraded are also possible in ISP deployments
and in those cases hosts will discover the DoH/DoT server hosted by the ISP.

Cheers,
-Tiru

On Mon, 20 Jul 2020 at 06:03, Martin Thomson <[email-masked]> wrote:

> Hi Tiru,
>
> I should remind you of the difference between describing a mechanism (as
> Vittorio did) and advocating for a particular policy regime.  This message
> appears to be the latter and therefore out of scope for this group.  If you
> want to continue that discussion, we're discussing
> https://tools.ietf.org/html/draft-thomson-tmi-00 on the [email-masked]
> list.
>

---

From: tirumal reddy <[email-masked]>
Date: Mon, 20 Jul 2020 15:24:50 +0530

On Mon, 20 Jul 2020 at 14:24, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> It depends on the implementation. In other cases, the filtering engine and
> the UI reside on the ISP's central resolver platform, and the CPE only adds
> an identifier (which can be generated locally and opaque) that allows the
> platform to tell which device is sending the query.
>

If the client uses DoH/DoT, the unique identifier can longer be sent in the
DNS request.

-Tiru

---

From: Neil Cook <[email-masked]>
Date: Mon, 20 Jul 2020 15:16:39 +0100

Hi Tiru,

> On 20 Jul 2020, at 10:54, tirumal reddy <[email-masked]> wrote:
> 
> On Mon, 20 Jul 2020 at 14:24, Vittorio Bertola <vittorio.bertola=[email-masked] <mailto:[email-masked]>> wrote:
>  
>> Il 20/07/2020 02:26 Kenji Baheux <kenjibaheux=[email-masked] <mailto:[email-masked]>> ha scritto:
>>  
>>  
> If the client uses DoH/DoT, the unique identifier can longer be sent in the DNS request.
> 

If the forwarder supports DoH/DoT as described in https://tools.ietf.org/html/draft-btw-add-home-07#section <https://tools.ietf.org/html/draft-btw-add-home-06#section-7>-7 then it can send any identifier it likes,

Neil

> [email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: Andrew Campling <[email-masked]>
Date: Mon, 20 Jul 2020 14:24:27 +0000

Kenji
Some ISPs use identifiers such as the device MAC address for parental controls, others implement the controls for the account rather than being device specific so cover all devices connected to the line.  The filtering itself is often requested during account application (ie at customer sign-up), with some ISPs offering several fixed levels of filtering (eg high, medium, low – with low often being the default), others do this and also offer customisation at account level.  And of course the filtering can be switched on or off at any point by the account holder.

I’ve copied my co-authors in case they wish to add any details on their own implementations as there will be variation between them.

Andrew

From: Kenji Baheux <[email-masked]>
Sent: 20 July 2020 01:27
To: tirumal reddy <[email-masked]>
Cc: Martin Thomson <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Which information is being used to dissociate the  devices?
What does the router do differently from there on? Where does the filtering actually occur, on the upstream resolver (different one?)?

Thanks.

On Fri, Jul 17, 2020 at 11:54 PM tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin,

Nowadays home routers are capable of running network security services. For example, DNS filtering to enforce MUD (https://tools.ietf.org/html/rfc8520) rules for IoT devices, blocking malware/phishing sites, parental control, anomaly detection etc.

SPAU allows the ISP DoH/DoT resolver to enforce DNS filtering for the entire home but cannot enforce device level filtering, isolate infected devices, identify local attacks etc.

Cheers,
-Tiru

On Thu, 16 Jul 2020 at 04:42, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andrew,

Cheers,
Martin

On Thu, Jul 16, 2020, at 02:59, Andrew Campling wrote:
> _https://datatracker...ietf.org/doc/html/draft-campling-operator-observations_<https://datatracker.ietf.org/doc/html/draft-campling-operator-observations_>
>
> [email-masked]<mailto:[email-masked]>, especially concerning any contributions from additional
> [email-masked]<mailto:[email-masked]>

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add

--
Kenji BAHEUX
Product Manager - Chrome
Google Japan

---

From: Andrew Campling <[email-masked]>
Date: Mon, 20 Jul 2020 14:47:32 +0000

> It would really help if the draft would clearly articulate what your desired outcome is.

Sorry for the lack of clarity.  The primary intent of the document is to provide information as we have the impression that at least some client developers may not have good visibility of common network operator architectures and practices outside of the US.  By providing such clarity we hope to see implementations that are sympathetic to the environment into which they are being deployed in order to maximise the chances of working correctly, ideally via SPAU as manual configuration of DNS settings by the majority of users seems unlikely.  

In a nut shell, any ADD solution should measure itself to see whether it meets the use case described in this document, at least one is needed that does.  

Andrew

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jul 2020 08:02:39 -0700

Hi Andrew,

Ignoring the discovery question for a moment, I guess I'm not entirely
clear on what your desired outcome in terms of network topology is.

As described in your draft, at present the clients send DNS packets to
the forwarder on the CPE, which then selectively forwards queries to
the main ISP resolver. However, in a world where the DNS is encrypted,
then this would require that the encryption be terminated at the
CPE and then re-originated to the ISP resolver, like so:

Client <------- TLS -------->  CPE  <------- TLS --------> ISP Resolver

Is that your desired outcome? If so, it seems to come into conflict
with your points in S 5.2 about the difficulty of upgrading the CPE.
If not, maybe I just don't understand. In either case, perhaps you
can elaborate.

-Ekr

On Mon, Jul 20, 2020 at 7:47 AM Andrew Campling
<[email-masked]> wrote:

> Sorry for the lack of clarity.  The primary intent of the document is to
> provide information as we have the impression that at least some client
> developers may not have good visibility of common network operator
> architectures and practices outside of the US.  By providing such clarity
> we hope to see implementations that are sympathetic to the environment into
> which they are being deployed in order to maximise the chances of working
> correctly, ideally via SPAU as manual configuration of DNS settings by the
> majority of users seems unlikely.
>
> In a nut shell, any ADD solution should measure itself to see whether it
> meets the use case described in this document, at least one is needed that
> does.
>
>
> Andrew
>
> --
> Add mailing list
> [email-masked]

---

From: Andrew Campling <[email-masked]>
Date: Mon, 20 Jul 2020 22:22:05 +0000

Ekr
To clarify, there are two issues to overcome here, (i) use of RFC1918 private addresses by the CPE (to facilitate SPAU) and (ii) support for DNS forwarders to maintain the full functionality provided by network operators that is described in the document.  The desired end state is as you describe:

Whilst it would be ideal to deal with both of the above issues simultaneously, pragmatically it may be necessary to deal with them sequentially given the potential for delays in upgrading CPE software.  Since there are already some proposed discovery methods that deal with the private addresses, it could make sense for to implement a two-step solution that first solves the private address issue in the short-term whilst the CPE software upgrade is deployed.  This would at least maintain support for the user’s chosen resolver via encrypted DNS using SPAU whilst a CPE software upgrade is QA’d by the network operator and then deployed.

Of course others may think it better to go with a single-step approach that upgrades the CPE software to maintain support for DNS forwarders and deals with the private address issue for SPAU at the same time.  However, since the timeframe for this will be necessarily longer for many users, my assumption is that the preference for most would be to enlarge the potential pool of encrypted DNS users as quickly as possible.

Does this help?

Andrew

From: Eric Rescorla <[email-masked]>
Sent: 20 July 2020 16:03
To: Andrew Campling <[email-masked]>
Cc: Martin Thomson <[email-masked]>; [email-masked]
Subject: Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Hi Andrew,

-Ekr

On Mon, Jul 20, 2020 at 7:47 AM Andrew Campling <[email-masked]<mailto:[email-masked]>> wrote:

Andrew

---

From: Kenji Baheux <[email-masked]>
Date: Tue, 21 Jul 2020 09:10:59 +0900

Thanks for the information thus far.

Assumption: I'm setting aside an auto-upgrade to a discovered DoH resolver
due to the lack of trust in any of the mechanism I'm aware of. Instead, I'm
currently assuming a world where a discovered DoH resolver would be
surfaced as an option (modulo some extra conditions TBD: recognized
provider, etc) for the user to choose.

Couldn't a CPE adjust its behavior and/or influence which DoH service gets
discovered (family-safe-strict.doh.isp.net, family-safe.doh.isp.net,
doh.isp.net) based on which device is asking (if at all, e.g. custom
filtering configured on the CPE => stop the discovery process in its track)?

   - What level of flexibility / capability can we roughly count on with
   the typical CPE today? Is the issue that the flexibility is so low that the
   above wouldn't work on most current CPEs?
   - Would these inflexible CPE be also incapable of halting any of the
   discovery process proposed thus far? What would be the bare minimum info
   that an ISP would need to know to avoid responding to a discovery process
   in case of these too old/.. CPE being in the loop? Or rather, would ISP be
   ok with responding to a discovery process if they get a confirmation that
   the CPE is up to the task?

On Mon, Jul 20, 2020 at 11:24 PM Andrew Campling
<[email-masked]> wrote:

> *Kenji*
>
> Some ISPs use identifiers such as the device MAC address for parental
> controls, others implement the controls for the account rather than being
> device specific so cover all devices connected to the line.  The filtering
> itself is often requested during account application (ie at customer
> sign-up), with some ISPs offering several fixed levels of filtering (eg
> high, medium, low – with low often being the default), others do this and
> also offer customisation at account level.  And of course the filtering can
> be switched on or off at any point by the account holder.
>
>
>
> I’ve copied my co-authors in case they wish to add any details on their
> own implementations as there will be variation between them.
>
>
>
>
>
> *Andrew*
>
>
>
> *From:* Kenji Baheux <[email-masked]>
> *Sent:* 20 July 2020 01:27
> *To:* tirumal reddy <[email-masked]>
> *Cc:* Martin Thomson <[email-masked]>; ADD Mailing list <[email-masked]>
> *Subject:* Re: [Add] Practical Observations from Encrypted DNS
> Deployments by Network Operators
>
>
>
> https://datatracker...ietf.org/doc/html/draft-campling-operator-observations_

-- 
Kenji BAHEUX
Product Manager - Chrome
Google Japan

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 21 Jul 2020 00:19:56 +0000

Hey Andrew,

Thank you for bringing this to the WG. I think it's important to talk through the ISP perspective. Given the two documents are intertwined, I'll address your proposal directly despite the subject being your informational document.

andrew> However, since the timeframe for this will be necessarily longer for many users, my assumption is that the preference for most would be to enlarge the potential pool of encrypted DNS users as quickly as possible.

Part of my feedback on this document was that this assumption does not hold true for me. I would rather avoid building protocols or systems we'll regret later than maximize the number of encrypted DNS users ASAP. I'm about to write out the verbose version of why I don't feel that way. Please feel free to correct anything I've misunderstood or overlooked.

In the spirit of ekr's calls for a threat model, let's walk through an attacker scenario. Let's say I discover 192.168.1.100 as a DNS server from my CPE from my home Wi-Fi network. I did this via DHCP, which is an insecure protocol. This proposal has a third party vouch for the authenticity, in this case, the separately maintained mapping by DNS client vendors.

I do not see this ISP list the same as the current Windows list of public DoH servers, and I am not willing to accept the risk posed by maintaining this new mapping. Where the existing SPAU list we rely on contains only publicly documented and PKI verifiable names, the proposed mechanism does not. This means I'm not just confirming what someone else has already validated; I'm now responsible for the maintenance of the original ownership verification for an ever-increasing number of ISPs which will include enterprises running their own internal networks also eager to avoid infrastructure updates on their end. I will not do that, especially for a stop-gap feature whose value will fade away as a proper bootstrapping mechanism is deployed.

The proposal I'm coauthoring (https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-01#section-5) won't work for RFC1918 addresses because they can't be verified using PKI. I'm ok with this, as DNS use of HTTPS should not be less secure than any other use of HTTPS.

Since DHCP discovery of 192.168.1.100 is insecure to start with and PKI can't be used to secure RFC1918 addresses, our choices are to invent a new trust mechanism (such as your proposal) or settle for opportunistic security. For example, a DNS client receiving an RFC1918 address can simply try it with DoT without concern for hostname. Literally just add TLS SPAU style. In a threat model, what this provides is protection against multiple eavesdroppers, reducing the eavesdropper count between the client and the CPE to a maximum of one (whoever convinces the client to use their spoofed DHCP message). It does not guarantee the identity of who you are sending queries to. However, this is no worse than before, as you have the same lack of authentication with classic DNS to a DHCP-discovered address but have now prevented eavesdropping by a third party.

If this is viewed as a regression because an attacker can then prevent the CPE from inspecting classic DNS traffic coming through it for ISP provided filtering purposes, then we're back to inventing a new trust mechanism. From my perspective, this is a non-starter. That leaves us with two alternatives I can think of: make DHCP (or its replacement) secure, or allow use of classic DNS on the client to CPE link. The former has previously been determined to be a hard problem. The latter is our current situation.

This is my in-depth way of asking: is rushing to get encrypted DNS to as many people as possible worth either settling for opportunistic protection or inventing a whole new trust mechanism (which will be permanent whether we wish it to be temporary or not, Paul Vixie recently shared some wisdom along this line)? My answer here in order are "maybe" and "no" but I'd like to hear what others think.

I hear you that deploying public DNS servers is costly and not within your interests. I also hear you that updating CPEs is time consuming. I simply don't see a way to avoid those things and continue to enable DNS to a CPE while providing the same level of security as DoH to a public resolver without either securing DHCP (which is hard and brings us back to updating CPEs) or inventing a new trust mechanism for private addresses (which adds a heavy burden to DNS clients for stop-gap work).

I welcome any comments or corrections. I'd be happy to be wrong.

Thanks,
Tommy Jensen
================================================
How can you secure your DNS queries? https://aka.ms/dohblogpost
________________________________
From: Add <[email-masked]> on behalf of Andrew Campling <[email-masked]>
Sent: Monday, July 20, 2020 3:22 PM
To: Eric Rescorla <[email-masked]>
Cc: [email-masked] <[email-masked]>; Martin Thomson <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Ekr

Does this help?

Andrew

Hi Andrew,

-Ekr

Andrew

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ce939e4d60ada409a069508d82cfb5d49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308805400763354&sdata=SfFJpJYzDQuVLtFDs2u8dQhejHa1%2FH1Tt%2B1tKnwBbPU%3D&reserved=0>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jul 2020 17:43:02 -0700

Thanks for the clarification.

On Mon, Jul 20, 2020 at 3:22 PM Andrew Campling
<[email-masked]> wrote:
> To clarify, there are two issues to overcome here, (i) use of RFC1918
> private addresses by the CPE (to facilitate SPAU) and (ii) support for
> DNS forwarders to maintain the full functionality provided by network
> operators that is described in the document.  The desired end state is
> as you describe:
>
>
>
> Whilst it would be ideal to deal with both of the above issues
> simultaneously, pragmatically it may be necessary to deal with them
> sequentially given the potential for delays in upgrading CPE software.
> Since there are already some proposed discovery methods that deal with
> the private addresses, it could make sense for to implement a two-step
> solution that first solves the private address issue in the short-term
> whilst the CPE software upgrade is deployed.

So the idea here would be to have a mechanism which enabled Do[TH] but
bypassed the CPE, correct? So, it would be something that one deployed
at the ISP's recursive and that we just expected the CPE to pass on?
It seems like the primary requirement there would be for something which
had a very high chance of passing through existing CPE.

With that said, I have some concerns about the objective of having the
CPE in the user's resolution path. While I certainly can understand
the reasons you consider it advantageous, it seems to me that it
significantly weakens the user's security posture. Even assuming
arguendo that we have a secure mechanism for discovering this case,
in practice the CPE seems to have quite a high rate of security
issues, including specifically DNS hijacking (see for instance [0]).
One of the advantages of Do[TH] from client to recursive is that
it has the potential to mitigate attacks from attackers on the network
-- including the local router -- and this seems like it would regress
that.

-Ekr

[0]
https://labs.bitdefender.com/2020/03/new-router-dns-hijacking-attacks-abuse-bitbucket-to-host-infostealer/

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Jul 2020 00:50:45 +0000

On Tuesday, 21 July 2020 00:43:02 UTC Eric Rescorla wrote:
> ... I have some concerns about the objective of having the
> significantly weakens the user's security posture.

yes.

> Even assuming

there's no method at present to distinguish dns hijacking from dns filtering, 
and dns filtering is an oft-used tool in network defense. sure one is the baby 
and the other is the bathwater, but how can an app know the difference?

> -- including the local router -- and this seems like it would regress

yes. because the internet is a network of networks, and the operators of edge 
networks may have policies which may be regulatory, and the users whose 
security posture concerns you may be minor children, employees, disgruntled 
employees, intruders, malicious or poisoned supply chains, or malware.

as the owner and operator of an edge network, i will be held responsible for 
the traffic leaving my network. i intend to exercise that responsibility. if 
this WG contemplates a design or feature which would obfuscate the difference 
between on-path actors who own and operate the edge network, as against on-
path actors who are upstream (like an evil ISP or authoritarian government), 
then we have to keep moving until we find a non-obfuscating security model.

-- 
Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jul 2020 02:15:24 +0100

Hiya,

On 21/07/2020 01:50, Paul Vixie wrote:
> because the internet is a network of networks, and the operators of edge 
> networks may have policies 

There's an interesting thing there - the current Internet,
with Cloudy-blah-services, CDNs, VPNs, Tor etc seems no
longer to be a network of networks that only touch at their
edges, but rather a network of networks some of which are
much more intimately entwined.

I don't have a solution to offer that solves all problems
in that context, but I do think it means that "my network,
my policy" is no longer as practical as was once the case.

Cheers,
S.

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Tue, 21 Jul 2020 01:30:21 +0000

I don’t see how an endpoint could distinguish between a malicious on-path device or service vs the CPE depicted in this flow:

This is equivalent to

Client  <------- TLS -------->  MitM Proxy  <------- TLS -------->  Any Website

Which is seems like a non-starter.

-Vinny

From: Add <[email-masked]> On Behalf Of Andrew Campling
Sent: Monday, July 20, 2020 6:22 PM
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]; Martin Thomson <[email-masked]>
Subject: Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Ekr

Does this help?

Andrew

From: Eric Rescorla <[email-masked] <mailto:[email-masked]> > 
Sent: 20 July 2020 16:03
To: Andrew Campling <[email-masked] <mailto:[email-masked]> >
Cc: Martin Thomson <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Hi Andrew,

-Ekr

On Mon, Jul 20, 2020 at 7:47 AM Andrew Campling <[email-masked] <mailto:[email-masked]> > wrote:

Andrew

---

From: tirumal reddy <[email-masked]>
Date: Tue, 21 Jul 2020 12:59:34 +0530

On Mon, 20 Jul 2020 at 19:46, Neil Cook <[email-masked]> wrote:

>> I'd like to get a clear picture of how per-device family-safe filtering
>> is typically configured in a plain ISP setup.
>>
>> It depends on the implementation. In other cases, the filtering engine
>> and the UI reside on the ISP's central resolver platform, and the CPE only
>> adds an identifier (which can be generated locally and opaque) that allows
>> the platform to tell which device is sending the query.
>>
>
> If the forwarder supports DoH/DoT as described in
> https://tools.ietf.org/html/draft-btw-add-home-07#section
> <https://tools.ietf.org/html/draft-btw-add-home-06#section-7>-7 then it
> can send any identifier it likes,
>

Yes, that would work.

-Tiru

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Jul 2020 09:39:34 +0200

On Mon, Jul 20, 2020 at 05:43:02PM -0700,
 Eric Rescorla <[email-masked]> wrote 
 a message of 111 lines which said:

> With that said, I have some concerns about the objective of having
> the CPE in the user's resolution path. While I certainly can
> understand the reasons you consider it advantageous, it seems to me
> that it significantly weakens the user's security posture. Even
> assuming arguendo that we have a secure mechanism for discovering
> this case, in practice the CPE seems to have quite a high rate of
> security issues, including specifically DNS hijacking (see for
> instance [0]).

Even without hijacking by a third-party (cracker with hoodie), the
local router is often controlled by the access provider which may be
the party you precisely want to work around. If you want to use DoE to
avoid the provider's lying resolver, using their router is not a smart
move.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Jul 2020 09:42:35 +0200

On Tue, Jul 21, 2020 at 02:15:24AM +0100,
 Stephen Farrell <[email-masked]> wrote 
 a message of 271 lines which said:

> There's an interesting thing there - the current Internet, with
> Cloudy-blah-services, CDNs, VPNs, Tor etc seems no longer to be a
> network of networks that only touch at their edges, but rather a
> network of networks some of which are much more intimately entwined.

RFC 8799 is an interesting reading here.

> I don't have a solution to offer that solves all problems in that
> context, but I do think it means that "my network, my policy" is no
> longer as practical as was once the case.

Also, I strongly object to this "my network, my policy" principle. I
want Internet access providers to be neutral tubes, not to force their
policies onto me.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 21 Jul 2020 10:55:24 +0200 (CEST)

>     Il 21/07/2020 02:43 Eric Rescorla <[email-masked]> ha scritto:
> 
> 
>     CPE in the user's resolution path.
> 
I just want to note that the mechanism described in the draft I recently posted ( https://datatracker.ietf.org/doc/draft-cook-doh-discovery-trial/?include_text=1 ) only goes through the CPE via Do53 in the discovery phase, then the DoH TLS connection bypasses the CPE and goes directly to the main resolver.

For ISPs and vendors that do filtering and other DNS-based services on the main recursor platform, this would be enough to let the current functionalities continue working.

Also - to a point by Kenji - you can't do that by picking from a finite set of preconfigured filtering options, e.g. "http://family-safe-strict.doh.isp.net ,http://family-safe.doh.isp.net ,http://doh.isp.net ", because current solutions offer complete control to end-users over the filtering configuration for each single device, even to the level of blocking or allowing individual domains if they like. There are people using filtering for purposes unrelated to parental control, for example SMBs blocking access to social media from the office during working hours.

--

---

From: <[email-masked]>
Date: Tue, 21 Jul 2020 09:15:15 +0000

Hi Vinny,

Please check https://tools.ietf.org/html/draft-btw-add-home-07#section-7 where we discuss how to put this in place.

Cheers,
Med

De : Add [mailto:[email-masked]] De la part de Vinny Parla (vparla)
Envoyé : mardi 21 juillet 2020 03:30
À : Andrew Campling <[email-masked]>; Eric Rescorla <[email-masked]>
Cc : [email-masked]; Martin Thomson <[email-masked]>
Objet : Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

This is equivalent to

-Vinny

From: Add <[email-masked]<mailto:[email-masked]>> On Behalf Of Andrew Campling
Sent: Monday, July 20, 2020 6:22 PM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Martin Thomson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Ekr

Does this help?

Andrew

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Sent: 20 July 2020 16:03
To: Andrew Campling <[email-masked]<mailto:[email-masked]>>
Cc: Martin Thomson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Hi Andrew,

-Ekr

Andrew

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Tue, 21 Jul 2020 09:24:57 +0000

I know it well.  Have provided out of band feedback on the proposals as you may be aware.

From: [email-masked] <[email-masked]> 
Sent: Tuesday, July 21, 2020 5:15 AM
To: Vinny Parla (vparla) <[email-masked]>
Cc: [email-masked]
Subject: RE: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Hi Vinny, 

Cheers,

Med

De : Add [mailto:[email-masked]] De la part de Vinny Parla (vparla)
Envoyé : mardi 21 juillet 2020 03:30
À : Andrew Campling <[email-masked] <mailto:[email-masked]> >; Eric Rescorla <[email-masked] <mailto:[email-masked]> >
Cc : [email-masked] <mailto:[email-masked]> ; Martin Thomson <[email-masked] <mailto:[email-masked]> >
Objet : Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

This is equivalent to

-Vinny

From: Add <[email-masked] <mailto:[email-masked]> > On Behalf Of Andrew Campling
Sent: Monday, July 20, 2020 6:22 PM
To: Eric Rescorla <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Martin Thomson <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Ekr

Does this help?

Andrew

Hi Andrew,

-Ekr

Andrew

---

From: tirumal reddy <[email-masked]>
Date: Tue, 21 Jul 2020 15:12:47 +0530

> issues, including specifically DNS hijacking (see for instance [0]).

Home routers are hardened (for example, see
https://www.mind.be/openwrtsummit18/2018-10-30-OpenWRT18-prplWRT.html) to
host network security services to protect the network from internal and
external attacks.

---

From: Andrew Campling <[email-masked]>
Date: Tue, 21 Jul 2020 10:06:00 +0000

On Tuesday, Jul 21, 2020 at 08:40, Stephane Bortzmeyer <[email-masked]> wrote:
> Even without hijacking by a third-party (cracker with hoodie), the local router is 
> often controlled by the access provider which may be the party you precisely 
> want to work around. 

In which case you already have other options including changing the router, configuring an alternate DNS provider and/or changing your access provider.  

> If you want to use DoE to avoid the provider's lying resolver, using their router is 
> not a smart move.

Ignoring the pejorative language, I feel that this is straying into policy areas and is therefore out of scope for the ADD charter and list.  Perhaps a discussion for another place such as the EDDI list?  

Andrew

---

From: Andrew Campling <[email-masked]>
Date: Tue, 21 Jul 2020 10:09:34 +0000

> want Internet access providers to be neutral tubes, not to force their 

I feel that this is again straying into policy areas and is therefore out of scope for the ADD charter and list.  

Andrew

---

From: tirumal reddy <[email-masked]>
Date: Tue, 21 Jul 2020 16:02:13 +0530

Hi Tommy,

Please see inline

On Tue, 21 Jul 2020 at 05:50, Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> Hey Andrew,
>
> Thank you for bringing this to the WG. I think it's important to talk
> through the ISP perspective. Given the two documents are intertwined, I'll
> address your proposal directly despite the subject being your informational
> document.
>
> andrew> However, since the timeframe for this will be necessarily longer
> for many users, my assumption is that the preference for most would be to
> enlarge the potential pool of encrypted DNS users as quickly as possible.
>
> Part of my feedback on this document was that this assumption does not
> hold true for me. I would rather avoid building protocols or systems we'll
> regret later than maximize the number of encrypted DNS users ASAP. I'm
> about to write out the verbose version of why I don't feel that way. Please
> feel free to correct anything I've misunderstood or overlooked.
>
> In the spirit of ekr's calls for a threat model, let's walk through an
> attacker scenario. Let's say I discover 192.168.1.100 as a DNS server from
> my CPE from my home Wi-Fi network. I did this via DHCP, which is an
> insecure protocol. This proposal has a third party vouch for the
> authenticity, in this case, the separately maintained mapping by DNS client
> vendors.
>

It is possible to host a DoT/DoH forwarder on the home router, the
forwarder can use a certificate that can be validated by PKI and the CPE
can continue to use private IP addresses. Please see
https://tools.ietf.org/html/draft-btw-add-home-07#section-7.1 for more
details.

>
> I do not see this ISP list the same as the current Windows list of public
> DoH servers, and I am not willing to accept the risk posed by maintaining
> this new mapping. Where the existing SPAU list we rely on contains only
> publicly documented and PKI verifiable names, the proposed mechanism does
> not. This means I'm not just confirming what someone else has already
> validated; I'm now responsible for the maintenance of the original
> ownership verification for an ever-increasing number of ISPs which will
> include enterprises running their own internal networks also eager to avoid
> infrastructure updates on their end. I will not do that, especially for a
> stop-gap feature whose value will fade away as a proper bootstrapping
> mechanism is deployed.
>
> The proposal I'm coauthoring (
> https://tools..ietf.org/html/draft-pauly-add-resolver-discovery-01#section-5
> <https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-01#section-5>)
> won't work for RFC1918 addresses because they can't be verified using PKI.
> I'm ok with this, as DNS use of HTTPS should not be less secure than any
> other use of HTTPS.
>
> Since DHCP discovery of 192.168.1.100 is insecure to start with and PKI
> can't be used to secure RFC1918 addresses, our choices are to invent a new
> trust mechanism (such as your proposal) or settle for opportunistic
> security. For example, a DNS client receiving an RFC1918 address can simply
> try it with DoT without concern for hostname.. Literally just add TLS SPAU
> style. In a threat model, what this provides is protection against multiple
> eavesdroppers, reducing the eavesdropper count between the client and the
> CPE to a maximum of one (whoever convinces the client to use their spoofed
> DHCP message). It does not guarantee the identity of who you are sending
> queries to. However, this is no worse than before, as you have the same
> lack of authentication with classic DNS to a DHCP-discovered address but
> have now prevented eavesdropping by a third party.
>
> If this is viewed as a regression because an attacker can then prevent the
> CPE from inspecting classic DNS traffic coming through it for ISP provided
> filtering purposes, then we're back to inventing a new trust mechanism.
> From my perspective, this is a non-starter. That leaves us with two
> alternatives I can think of: make DHCP (or its replacement) secure, or
> allow use of classic DNS on the client to CPE link. The former has
> previously been determined to be a hard problem. The latter is our current
> situation.
>
> This is my in-depth way of asking: is rushing to get encrypted DNS to as
> many people as possible worth either settling for opportunistic protection
> or inventing a whole new trust mechanism (which will be permanent whether
> we wish it to be temporary or not, Paul Vixie recently shared some wisdom
> along this line)? My answer here in order are "maybe" and "no" but I'd like
> to hear what others think.
>
> I hear you that deploying public DNS servers is costly and not within your
> interests. I also hear you that updating CPEs is time consuming. I simply
> don't see a way to avoid those things and continue to enable DNS to a CPE
> while providing the same level of security as DoH to a public resolver
> without either securing DHCP (which is hard and brings us back to updating
> CPEs) or inventing a new trust mechanism for private addresses (which adds
> a heavy burden to DNS clients for stop-gap work).
>

The home network itself is susceptible to both internal and external
attacks. https://tools.ietf.org/html/draft-btw-add-home-07#section-9 discusses
various attacks possible and the mechanisms endpoint can use to avoid using
the attacker's DoH/DoT server.

Cheers,
-Tiru

> ------------------------------
> *From:* Add <[email-masked]> on behalf of Andrew Campling
> <[email-masked]>
> *Sent:* Monday, July 20, 2020 3:22 PM
> *To:* Eric Rescorla <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>; Martin Thomson <[email-masked]>
> *Subject:* [EXTERNAL] Re: [Add] Practical Observations from Encrypted DNS
> *Ekr*
> private addresses by the CPE (to facilitate SPAU) and (ii) support for DNS
> forwarders to maintain the full functionality provided by network operators
> that is described in the document.  The desired end state is as you
> describe:
>
>
>
> Since there are already some proposed discovery methods that deal with the
> private addresses, it could make sense for to implement a two-step solution
> that first solves the private address issue in the short-term whilst the
> CPE software upgrade is deployed.  This would at least maintain support for
> the user’s chosen resolver via encrypted DNS using SPAU whilst a CPE
> software upgrade is QA’d by the network operator and then deployed.
>
>
>
> Of course others may think it better to go with a single-step approach
> that upgrades the CPE software to maintain support for DNS forwarders and
> deals with the private address issue for SPAU at the same time.  However,
> since the timeframe for this will be necessarily longer for many users, my
> assumption is that the preference for most would be to enlarge the
> potential pool of encrypted DNS users as quickly as possible.
>
>
>
> Does this help?
>
>
>
>
>
> *Andrew*
>
>
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* 20 July 2020 16:03
> *To:* Andrew Campling <[email-masked]>
> *Cc:* Martin Thomson <[email-masked]>; [email-masked]
> On Mon, Jul 20, 2020 at 7:47 AM Andrew Campling <
> [email-masked]> wrote:
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ce939e4d60ada409a069508d82cfb5d49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308805400763354&sdata=SfFJpJYzDQuVLtFDs2u8dQhejHa1%2FH1Tt%2B1tKnwBbPU%3D&reserved=0>
>
> --
> Add mailing list
> [email-masked]

---

From: Andrew Campling <[email-masked]>
Date: Tue, 21 Jul 2020 11:36:08 +0000

On Tues, Jul 21, 2020 at 01:20 Tommy Jensen <[email-masked]> wrote:

> Part of my feedback on this document was that this assumption does not hold true for me. I would rather avoid building protocols or systems we'll regret later than maximize the number of encrypted DNS users ASAP.

I think it would be beneficial to have further discussion whether the IETF's policy of encrypting end-to-end communication comes with an implied requirement to do so as quickly as possible (another way of looking at maximizing the number of encrypted DNS users ASAP), or whether this can be done so in a more leisurely manner.  I appreciate that having this discussion is counter to the ADD charter so it has to be had elsewhere, perhaps someone could suggest an appropriate IETF venue?  Or could this take place within the EDDI list?

Andrew

---

From: Jim Reid <[email-masked]>
Date: Tue, 21 Jul 2020 12:41:29 +0100

> On 21 Jul 2020, at 12:36, Andrew Campling <[email-masked]> wrote:
> 
> I think it would be beneficial to have further discussion whether the IETF’s policy of encrypting end-to-end communication comes with an implied requirement to do so as quickly as possible (another way of looking at maximizing the number of encrypted DNS users ASAP), or whether this can be done so in a more leisurely manner.  I appreciate that having this discussion is counter to the ADD charter so it has to be had elsewhere, perhaps someone could suggest an appropriate IETF venue?  

The dprive WG would appear to be the right place for discussing encryption of DNS traffic. If you’re looking at end-to-end communications in general, that’s probably far too big and diffuse a topic to sit inside a single, all-encompassing tent.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 21 Jul 2020 14:23:30 +0200 (CEST)

> Il 21/07/2020 13:41 Jim Reid <[email-masked]> ha scritto:
> 

Well, RFC 7258 is the IETF's policy statement from which Tommy's question descends, so where was it discussed and approved at the time? That would look like an appropriate venue.

By the way, the policy dimensions hit by that question are multiple and go way beyond the simple strive for encryption or for technical security. Some parties will prefer continuing to use the local resolver with encrypted DNS, even if discovered through a process which is only 99.99% secure, rather than switching to an open global resolver that can be authenticated with 100% certainty. I think that the IETF should provide the tools so that both things can happen easily, and then the decision on what to implement is likely to be non-technical and not driven by threat models (e.g. in Europe there currently are a lot of concerns and political debates about consolidation, competition and "self-preferencing" by the big platforms against local operators, so I wouldn't be surprised if this popped up there).

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jul 2020 13:25:12 +0100

On 21/07/2020 13:23, Vittorio Bertola wrote:
> Well, RFC 7258 is the IETF's policy statement from which Tommy's
> question descends, so where was it discussed and approved at the
> time?
[email-masked], in about 1000+ messages ;-)

S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2020 05:28:43 -0700

> host network security services to protect the network from internal and

Some home routers are hardened, but as the link I posted indicated, many
are not.

-Ekr

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Jul 2020 15:57:08 +0200

On Tue, Jul 21, 2020 at 10:06:00AM +0000,
 Andrew Campling <[email-masked]> wrote 
 a message of 23 lines which said:

> > If you want to use DoE to avoid the provider's lying resolver,
> > using their router is not a smart move.
> 
> Ignoring the pejorative language,

Sorry for using the correct word.

> I feel that this is straying into policy areas and is therefore out
> of scope for the ADD charter and list.

Discussing the threat model is certainly fundamentally in-scope.

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 21 Jul 2020 15:35:29 +0000

Hey Tiru,

Thanks for sharing. In section 7 of your draft which defines the mechanism you’re proposing for PKI secures communication with an RFC1918 address, I see one problem:

> Let's suppose that "example.net" is pre-configured as a verified resolved in the browser or OS.

This depends on the DNS client already having “example.com” configured as a resolver. This doesn’t scale well. In order for a client to work out of the box with my ISP, it would need to come preconfigured with all known ISPs or provide a UX to add example.com as a resolver. The first doesn’t scale any better than pre-shared HOSTS files, and the second requires the user to get involved rather than providing security by default. While we are using a pre shared list today, it’s incredibly short and not a viable solution in the long term nor something I would want have as a requirement for mainstream consumer scenarios.

One approach (which may be in your draft and I simply missed it) would be to make a connection to the parent of the DHCP/RA domain by dropping the leftmost labels and verify the certificate the same way. I would expect the CPE to provide the IP hint for that resolver as well. This at least would allow bootstrapping without any preconfiguration or user involvement needed unless I’m missing something? This should negate the need for the work described here requiring other token types for going from a DHCP message with novel server identifiers to a secure DNS connection to a local address.

> If the insecurely discovered DoH/DoT server is not pre-configured in the OS or browser, the client must validate the signatory (e.g., cryptographically attested by the ISP [I-D.reddy-add-server-policy-selection<https://tools.ietf.org/html/draft-btw-add-home-07#ref-I-D.reddy-add-server-policy-selection>]).

Thanks,
Tommy Jensen

________________________________
From: Add <[email-masked]> on behalf of tirumal reddy <[email-masked]>
Sent: Tuesday, July 21, 2020 3:32 AM
To: Tommy Jensen <Jensen.Thomas=[email-masked]>
Cc: Andrew Campling <[email-masked]>; [email-masked] <[email-masked]>; Eric Rescorla <[email-masked]>; Martin Thomson <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Hi Tommy,

Please see inline

On Tue, 21 Jul 2020 at 05:50, Tommy Jensen <Jensen.Thomas=[email-masked]<mailto:[email-masked]>> wrote:
Hey Andrew,

It is possible to host a DoT/DoH forwarder on the home router, the forwarder can use a certificate that can be validated by PKI and the CPE can continue to use private IP addresses. Please see https://tools.ietf..org/html/draft-btw-add-home-07#section-7.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-btw-add-home-07%23section-7.1&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca9c32a64e4c2414a4bb508d82d6162d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309243589465652&sdata=ITEhDe%2FhKwhBMyLl5bFxJ3zns8la6KaUI%2FaoTH4MdzA%3D&reserved=0> for more details.

The proposal I'm coauthoring (https://tools..ietf.org/html/draft-pauly-add-resolver-discovery-01#section-5<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-pauly-add-resolver-discovery-01%23section-5&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca9c32a64e4c2414a4bb508d82d6162d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309243589465652&sdata=FQHFqfeWey6sMwZbHz9o6Fk6ZF88QVE%2FC3ZayUwg8yE%3D&reserved=0>) won't work for RFC1918 addresses because they can't be verified using PKI. I'm ok with this, as DNS use of HTTPS should not be less secure than any other use of HTTPS.

Since DHCP discovery of 192.168.1.100 is insecure to start with and PKI can't be used to secure RFC1918 addresses, our choices are to invent a new trust mechanism (such as your proposal) or settle for opportunistic security. For example, a DNS client receiving an RFC1918 address can simply try it with DoT without concern for hostname... Literally just add TLS SPAU style. In a threat model, what this provides is protection against multiple eavesdroppers, reducing the eavesdropper count between the client and the CPE to a maximum of one (whoever convinces the client to use their spoofed DHCP message). It does not guarantee the identity of who you are sending queries to. However, this is no worse than before, as you have the same lack of authentication with classic DNS to a DHCP-discovered address but have now prevented eavesdropping by a third party.

The home network itself is susceptible to both internal and external attacks. https://tools.ietf.org/html/draft-btw-add-home-07#section-9<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-btw-add-home-07%23section-9&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca9c32a64e4c2414a4bb508d82d6162d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309243589465652&sdata=uXOEKmG0kIWFlDP%2BZpj%2FKVA3mlytZrW1wu4HlagbL40%3D&reserved=0> discusses various attacks possible and the mechanisms endpoint can use to avoid using the attacker's DoH/DoT server.

Cheers,
-Tiru

Thanks,
Tommy Jensen
================================================
How can you secure your DNS queries? https://aka.ms/dohblogpost
________________________________
From: Add <[email-masked]<mailto:[email-masked]>> on behalf of Andrew Campling <[email-masked]>
Sent: Monday, July 20, 2020 3:22 PM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

Ekr

Does this help?

Andrew

Hi Andrew,

-Ekr

Andrew

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca9c32a64e4c2414a4bb508d82d6162d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309243589475649&sdata=TJ3kxJ%2BwN7yvYs0j6zMHahyxDSH2Q%2BeKMUHzwaOTG2I%3D&reserved=0>

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca9c32a64e4c2414a4bb508d82d6162d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309243589485641&sdata=UduP65SRKh5Y5vgz0Bgvp5zWt10MQN1UdvWXdaPlNJ0%3D&reserved=0>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Jul 2020 17:50:38 +0200

On Tue, Jul 21, 2020 at 03:35:29PM +0000,
 Tommy Jensen <Jensen.Thomas=[email-masked]> wrote 
 a message of 865 lines which said:

> One approach (which may be in your draft and I simply missed it)
> would be to make a connection to the parent of the DHCP/RA domain by
> dropping the leftmost labels and verify the certificate the same
> way.

"Climbing the tree" is dangerous since you don't know when you cross
an administrative boundary (see the relics of the DBOUND working
group). Can eu.org vouch for something.eu.org?

RFC 1535 is still relevant...

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Jul 2020 16:49:31 +0000

> scope for the ADD charter and list.

part of it is in-scope, and stephane's misunderstanding as quoted above 
illuminates this perfectly. i, like him, do not expect my ISP to have a policy 
beyond anti-abuse, because they have no enforcement capability beyond that, 
and because they do not also own the end-devices nor employ or parent the end-
users. anti-abuse means if they let their users spam or ddos, or if they host 
harmful content, they'll face consequences. however for the purpose of this WG 
i will stipulate that an ISP ought not dictate DNS policy to its customers.

the misunderstanding comes in the network-of-networks concept. my edge network 
is not an ISP. it's a LAN, perhaps containing a bridged WLAN, or a small or 
virtual campus containing many LANs. the edge is a private artifact, crafted 
by me in the case of my family and my day job, paid for by my family or my 
company. all devices connected to the edge network are owned by the same 
family or company who constructed and operates that network, and who pays for 
an ISP connection to connect this network to the rest of the network of 
networks ("internet").

in the hierarchy of responsibility, ISP's have far less than edge network 
operators. exercise of whatever responsibilities a network (ISP or edge) 
operator should not be challenged nor should this hierarchy be upended by new 
protocol standards such as those discussed in this WG. there's already a Tor 
project, and there are hundreds of private tunnel methods available on github, 
so that hostile use of an edge network ("hostile" meaning the user disagrees 
with the owner/operator's policies) can proceed.

a solid engineering plan and associated protocol for DNS discovery would allow 
an edge network operator to reliably express its resources and policies to 
connected devices, and to reliably detect and prohibit violations of that 
policy. if DHCP is inadequate to tell devices what DNS server to use and what 
protocols and crypto algs and keys to use, then we should define a new way to 
do that which lacks DHCP's inadequacies. but we should also respect the edge 
network operator's ability to set and enforce policy for the private network 
they build, operate, and pay for.

"should" in this case is not because of ethics, but because of practicalities: 
corporate, private, government, military, and other sensitive networks _will 
not_ have their architecture dictated to them. sometimes this is by law, or by 
regulation, or enlightened self interest (defense) or just plain stubbornness. 
if the new way to DNS disintermediates edge network policy, then the result 
will be some combination of losses due to disappearance of defense technology, 
and explicit edge proxies which force cleartext inspection of traffic.

the IETF should not implicitly legislate edge network policy by creation of 
new standards. and if i see that trying to happen on the ADD list, i will 
object, because that objection will be on-topic.

apple has done a lot of work in the area of discovering local-network policy, 
i believe it relies on broadcast/multicast as a way to differentiate between 
edge operators (who can hear multicast from a connected device) and ISP's (who 
cannot). while there are some weaknesses like authentication, the model is 
sound: it assumes that the local network operator knows what policy they want 
or need or are required to implement, and ISP's have no role in it other than 
offering resources.

this is why i think glenn's tri-color model is essential for our discussions.

(sometimes i'm told that edge networks are an anachronism and that the 
internet should be considered public from end to end. i don't know what to 
tell folks except, please get out there and try to sell that idea and see who 
bites, but don't ram it down anybody's throat if they just plain disagree. the 
first few thousand networks to join the "network of networks" ("Internet") 
were all privately owned and operated. third-party transit came later.)

-- 
Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Jul 2020 17:06:46 +0000

On Tuesday, 21 July 2020 11:36:08 UTC Andrew Campling wrote:
> > hold true for me. I would rather avoid building protocols or systems
> > we'll regret later than maximize the number of encrypted DNS users ASAP.
> I think it would be beneficial to have further discussion whether the IETF's
> policy of encrypting end-to-end communication comes with an implied
> requirement to do so as quickly as possible (another way of looking at
> maximizing the number of encrypted DNS users ASAP), or whether this can be
> done so in a more leisurely manner.  ...

everything we do with internet protocols has a long tail. there is always a 
motive to get it right rather than ship it fast. if someone is having a raging 
surveillance fire, there's NLNetLabs "stubby" and similar software from CF. we 
should not treat the future of DNS encryption as a raging fire.

-- 
Paul

---

From: Neil Cook <[email-masked]>
Date: Tue, 21 Jul 2020 19:14:47 +0100

> On 21 Jul 2020, at 08:39, Stephane Bortzmeyer <[email-masked]> wrote:
> 

What does this comment have to do with ADD? People are free to choose their CPE. If you don’t want to use the access provider’s resolver, use a different one.

Neil

---

From: Neil Cook <[email-masked]>
Date: Tue, 21 Jul 2020 19:21:44 +0100

> On 21 Jul 2020, at 01:43, Eric Rescorla <[email-masked]> wrote:
> 
> 

It doesn’t weaken the security posture vs the current situation, which Andrew’s draft attempts to detail, and which is very widely deployed, i.e. CPEs forwarding Do53 to a Do53 recursor.

> -- including the local router -- and this seems like it would regress

It’s not perfect (nothing is), but it’s better than the status quo. 

Neil

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 21 Jul 2020 14:42:25 -0400

Hi Paul,

Perhaps given your model, you might appreciate the CPE (a/k/a middlebox) 
protocol initiative to provide shared endpoint and provider control of 
CPE discovery and behavior. The challenges here are non-trivial. The 
near final version of the baseline part is attached.  Significant credit 
should be given to David Naylor as it originated as his CMU PhD thesis.

I also haven't forgot our previous dialogue on competition complexities, 
but chose to spend the time researching and writing on CircleID. 
http://www.circleid.com/posts/20200711-addressing-anticompetitive-behaviur-in-internet-standards-bodies/

Over the past 30 years, the IETF's track record in understanding the 
adverse effects of actions relating to competition, trust, and security 
has been mixed at best.

best,
tony

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 21 Jul 2020 12:47:01 -0600

neil.cook> What does this comment have to do with ADD? People are free
neil.cook> to choose their CPE. If you don't want to use the access
neil.cook> provider's resolver, use a different one.

The problem is that this isn't an option for everyone... Some ISPs
mandate what CPE and keep admin control or you don't get internet. And
some markets don't have robust multiple choices of provider, such that
you can just go to another provider.

CPEs are problematic as a mandated part of any solution because:

  - not everyone owns or can pick their CPE (or even change settings on it)
  - many CPEs are kept unpatched for years until the magic blue smoke
    pours out the back and they are replaced with another crappy CPE
  - many CPEs aren't field upgradeable

It is certainly better if we can change/fix/update the CPE but enough of
the time this isn't a timely option and we should reflect that in
documents we produce.

---

From: Neil Cook <[email-masked]>
Date: Tue, 21 Jul 2020 19:53:14 +0100

> On 21 Jul 2020, at 01:19, Tommy Jensen <[email-masked]> wrote:
> 

I would like to point out that, if you strip away the policy aspects of the draft, the technical mechanism is very similar to that of RESINFO (and indeed the proposal that ekr/Comcast co-authored), in that it uses a DNS lookup to find a DoH resolver. 

> This is my in-depth way of asking: is rushing to get encrypted DNS to as many people as possible worth either settling for opportunistic protection or inventing a whole new trust mechanism (which w…

Opportunistic protection is better than the current situation, so my answer to the first question would be “yes”.

> How can you secure your DNS queries? https://aka.ms/dohblogpost <https://aka.ms/dohblogpost> 
> On Mon, Jul 20, 2020 at 7:47 AM Andrew Campling <[email-masked] <mailto:[email-masked]>> wrote:
> On Thu, Jul 16, 2020, at 00:12, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> https://www.ietf.org/mailman/listinfo/add <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ce939e4d60ada409a069508d82cfb5d49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308805400763354&sdata=SfFJpJYzDQuVLtFDs2u8dQhejHa1%2FH1Tt%2B1tKnwBbPU%3D&reserved=0>

---

From: Neil Cook <[email-masked]>
Date: Tue, 21 Jul 2020 20:22:17 +0100

> On 21 Jul 2020, at 19:47, Paul Ebersman <[email-masked]> wrote:
> 

Fair point.

>  - many CPEs aren't field upgradeable

I don’t know of any drafts which are mandating CPEs as part of a solution. However I do think that’s it really important that this WG understands how widely deployed they are as forwarders, and that the solutions we come up with take that into account. A lot of folks seem to assume that there is only one model that is relevant, which is client direct to eventual resolver.

> the time this isn't a timely option and we should reflect that in
Agreed.

Neil

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 16:03:23 -0400

> want Internet access providers to be neutral tubes, not to force their

It seems that you are arguing for exactly, "my network, my policy" not
against it.

You want *my computer, my policy*, and you don't want Internet access
providers to force their policy of bypassing your local security mechanisms
to be forced upon you.
You are exacly in the same camp as Paul Vixie, in my opinion, you just say it
a different way.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 16:11:12 -0400

> avoid the provider's lying resolver, using their router is not a smart

1) I point at "often", but, it's not exclusively.
   The provider can also do all sorts of bad things to your packets.
   The provider is usually fabicating false responses for reasons that they
   think are good.  They usually aren't trying to hide the fact that they are
   doing this, so, they will usually be willing to state that policy.
   (which is completely in-scope for this group).
   [Yes, there are the wildcard advertising attacks, but let's let them be
   out of scope for now]

2) TR 369 provides for split control of the CPE device.  That's not here yet,
   but there are many who are pushing for it.
   Plan for accomodating that.

3) there are often more than two parties involved: an access provider, an IT
   support entity, and the owner.
   This is extremely common for small businesses, which typically are using
   "home" equipement.  The router is usually managed by the IT support
   entity, which is often called a "business to business ISP".
   They usually don't want to try to compete on bandwidth/connectivity, so
   they often resell the ISP connections.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jul 2020 16:20:10 -0400

> You are exacly in the same camp as Paul Vixie, in my opinion, you just say it

Not exactly. Both he and Paul want autonomy. But they are operating different parts of the network hierarchy, and so what they have to do to get that autonomy is different (and likely antithetical).

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 16:22:41 -0400

> significantly weakens the user's security posture.

It's a question of point of view.
While you feel that we can't trust any of the CPEs out there, many of us feel
that we can't trust any of the desktop PCs out there.  They are infested.
And even devices from vendors who say they care about our privacy, seem not
willing to use the DNS settings we tell them.

Let me rewrite your words from the point of view of many of us,
perhaps I will succeed in channeling Paul's point.

    mcr> Even assuming
    mcr> arguendo that we have a secure mechanism for discovering this case,
    mcr> in practice the PC desktop WEB BROWSER and IoT devices seems to have quite a high rate of security
    mcr> issues, including specifically DNS spoofing, since the browsers do not
    mcr> do DNSSEC even though they could.
    mcr> One of the advantages of DoT from client to the locally configured recursive is that
    mcr> it has the potential to mitigate attacks from attackers on the network
    mcr> -- including adjacent desktop PCs -- and this seems like it would regress
    mcr> that.

I also have a document draft-richardson-opsawg-mud-iot-dns-considerations-02
that deals with DNS issues as they relate to RFC8520(MUD).
Use of non-local DNS resolvers screws with our ability to easily write MUD
files for devices.  Mostly due to reasons of geolocation of DNS.

So, we have to come up with a mechanism where the CPE can be in the device's
resolution path, and when that is the case, we need to reliably inform the
user of what the resolution path is at the time.

[Please note where I said device rather than user]

---

From: Paul Ebersman <[email-masked]>
Date: Tue, 21 Jul 2020 14:31:31 -0600

neil.cook> I don't know of any drafts which are mandating CPEs as part
neil.cook> of a solution. However I do think that's it really important
neil.cook> that this WG understands how widely deployed they are as
neil.cook> forwarders, and that the solutions we come up with take that
neil.cook> into account. A lot of folks seem to assume that there is
neil.cook> only one model that is relevant, which is client direct to
neil.cook> eventual resolver.

Agree. "common" implementation models runs the gamut and we should
acknowledge that.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2020 13:45:11 -0700

On Tue, Jul 21, 2020 at 1:22 PM Michael Richardson <[email-masked]>
wrote:

> the

> Michael,

I think we are now verging into the kind of policy territory which is out
of scope for this WG.

In any case, the point I was making was specific to CPE: it's one thing to
have the client detect and use the ISP's resolver; it's quite another to
have it use the CPE. For the same reason that it's hard to upgrade the CPU
(as noted in the draft that started this thread) it's also hard to secure
it. This is not true for either the ISP's resolver or, incidentally, for
Web browsers, though it is true for many IoT devices. Thus, it seems like
having the client detect and use the CPE significantly worsens the user's
posture vis-a-vis them using the ISP resolver.

    mcr> Even assuming
>     mcr> do DNSSEC even though they could.

This claim seems to have two parts:

1. Doing DNSSEC validation would significantly decrease the high rate of
DNS spoofing.
2. That the browsers in fact could do DNSSEC validation.

As far as I know, it's an open question whether either of these is true. Do
you have measurements that support either (1) that DNS spoofing happens
frequently and would be prevented by DNS [note that due to the high
fraction of connections which are secured by TLS, the impact of such
spoofing would be modest in many cases] or (2) that browsers could safely
do DNSSEC validation without experiencing unacceptable false positive rates?

-Ekr

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Jul 2020 20:58:34 +0000

On Tuesday, 21 July 2020 20:20:10 UTC Ted Lemon wrote:
> > ...
> > You are exacly in the same camp as Paul Vixie, in my opinion, you just say
> > it a different way.
> 
> Not exactly. Both he and Paul want autonomy. But they are operating
> different parts of the network hierarchy, and so what they have to do to
> get that autonomy is different (and likely antithetical).

i feel sure that stephane and i both operate edge networks (so, same part of the 
hierarchy) and that neither of us wants our policies for such networks dictated to us, 
either by iot devices, browser makers, isp's, governments, or end users. there may be a 
distinction here but there is not a difference.

-- 
Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Jul 2020 21:58:49 +0000

> my policy" is no longer as practical as was once the case.

if i pay for its upkeep, am responsible for its emissions, own every device connected to it, 
and either employ or am otherwise legally responsible for the actions of its users, then i 
will make the final decision over how it's used.

and i don't think anyone here is going to say "paul you're wrong, the internet exists apart 
from you, your responsibility is just to extend it and then let any browser vendor or iot 
device do whatever they want, it's viral now, all public property, including the parts you're 
paying for."

so if we could dispense with blurred distinctions between private-access edge networks 
and public-access ISP and core networks, i'd like to get back to the topic ADD is for: how 
will we securely inform connected devices of the local network's resources and policies 
(e.g., DNS settings), and how will we ensure that private-access edge networks can 
monitor and control policy compliance?

-- 
Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2020 15:02:18 -0700

> posture vis-a-vis them using the ISP resolver.

And just to clarify, I don't think these comments necessarily apply to
enterprise edge routers. I'm really talking specifically about the
advisability of keeping a set of devices we know to have severe security
problems in the loop.

-Ekr

> As far as I know, it's an open question whether either of these is true.
> Do you have measurements that support either (1) that DNS spoofing happens

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 21 Jul 2020 22:41:02 +0000

In-line as [BHS].
Barbara

From: Eric Rescorla

On Tue, Jul 21, 2020 at 1:22 PM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

I think we are now verging into the kind of policy territory which is out of scope for this WG.

In any case, the point I was making was specific to CPE: it's one thing to have the client detect and use the ISP's resolver; it's quite another to have it use the CPE. For the same reason that it's hard to upgrade the CPU (as noted in the draft that started this thread) it's also hard to secure it. This is not true for either the ISP's resolver or, incidentally, for Web browsers, though it is true for many IoT devices. Thus, it seems like having the client detect and use the CPE significantly worsens the user's posture vis-a-vis them using the ISP resolver.

[BHS] While my ISP requires me to use the CE router they supply, I’ve never had an issue connecting that to my own router and then running my home network from my router. The CE router from my particular ISP (YMMV) even automatically passes on the public IPv4 address it acquires and a /64 IPv6 prefix to my router (so IPv4 just has the single NAT and IPv6 works great). I have total ability to choose any router I want and configure that router as much as that router vendor’s GUI allows (e.g., Netgear GUIs don’t let you configure the DNS server info it supplies to the LAN via DHCP, etc. – it always supplies its own IP address; it does let the user say whether its proxy will use DNS info it gets via DHCP or configure static DNS info). It seems to me that anyone who is concerned with what the ISP can do vis-à-vis their home network should be firewalling the ISP CE router, anyway. I’m at a loss to understand why people are considered “forced” to use the ISP CE router as their home network router, just because they’re forced to use it to terminate the ISP WAN connection. I do understand that people do this for ease and convenience. But those same people are also unlikely to care about changing away from the ISP resolvers. If you care enough to want to configure the DNS used in your home network, you should care enough to run your own router between your network and the ISP “WAN termination device”. --Barbara

    mcr> Even assuming

1. Doing DNSSEC validation would significantly decrease the high rate of DNS spoofing.
2. That the browsers in fact could do DNSSEC validation.

As far as I know, it's an open question whether either of these is true. Do you have measurements that support either (1) that DNS spoofing happens frequently and would be prevented by DNS [note that due to the high fraction of connections which are secured by TLS, the impact of such spoofing would be modest in many cases] or (2) that browsers could safely do DNSSEC validation without experiencing unacceptable false positive rates?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2020 15:54:01 -0700

On Tue, Jul 21, 2020 at 3:41 PM STARK, BARBARA H <[email-masked]> wrote:

> *[BHS] While my ISP requires me to use the CE router they supply, I’ve
> never had an issue connecting that to my own router and then running my
> home network from my router. The CE router from my particular ISP (YMMV)
> even automatically passes on the public IPv4 address it acquires and a /64
> IPv6 prefix to my router (so IPv4 just has the single NAT and IPv6 works
> great). I have total ability to choose any router I want and configure that
> router as much as that router vendor’s GUI allows (e.g., Netgear GUIs don’t
> let you configure the DNS server info it supplies to the LAN via DHCP, etc.
> – it always supplies its own IP address; it does let the user say whether
> its proxy will use DNS info it gets via DHCP or configure static DNS info).
> It seems to me that anyone who is concerned with what the ISP can do
> vis-à-vis their home network should be firewalling the ISP CE router,
> anyway. I’m at a loss to understand why people are considered “forced” to
> use the ISP CE router as their home network router, just because they’re
> forced to use it to terminate the ISP WAN connection. I do understand that
> people do this for ease and convenience. But those same people are also
> unlikely to care about changing away from the ISP resolvers. If you care
> enough to want to configure the DNS used in your home network, you should
> care enough to run your own router between your network and the ISP “WAN
> termination device”. --Barbara*
>

I'm not quite sure what you're responding to here, because I didn't say
anything about forced, and the concern I'm raising here is not about the
ISP doing things vis-a-vis the user's home network but *attackers* doing
things by compromising the ISP-provided CE router.

The context of this discussion as I understand it is this:
A number of endpoints are using SPAU mechanisms for converting from Do53 to
Do[TH]. This draft points out that this has the potential to cause the
endpoint to connect directly to the ISP's resolver, bypassing the CPE and
any functions that the CPE performs (presumably the ISP resolver could
perform some but not all of these) and proposes that we develop some
mechanism to avoid bypassing the CPE. At least from my perspective this
particular discussion is not about the ISP versus the consumer but about
whether it is advisable to design a mechanism to keep the CPE in the loop.

-Ekr

---

From: Ted Hardie <[email-masked]>
Date: Tue, 21 Jul 2020 16:10:51 -0700

Howdy,

On Tue, Jul 21, 2020 at 2:59 PM Paul Vixie <[email-masked]> wrote:

>  i'd like to get back to the topic ADD is for: how will we securely inform
> connected devices of the local network's resources and policies (e.g., DNS
> settings), and how will we ensure that private-access edge networks can
> That's a more expansive reading of our charter than I think is warranted.
Here's a reminder of our deliverables:

The Adaptive DNS Discovery (ADD) working group will work on the following
deliverables:

- Define a mechanism that allows clients to discover DNS resolvers
that support encryption and that are available to the client
either on the public Internet or on private or local networks.

- Define a mechanism that allows communication of DNS resolver
information to clients for use in selection decisions. This could be
part of the mechanism used for discovery, above.

- Develop an informational document that describes mechanisms for
clients to detect specific network environments (such as captive portal
and split horizon) and to use that information to inform their DNS
configuration.
I don't see any deliverables that cover "and how will we ensure that
private-access edge networks can monitor and control policy compliance?"
ADD will specify a mechanism to allow clients to discover DNS resolvers and
a mechanism to communicate resolver information *for the clients to use in
selection decisions*.  I don't see an action item in this group for
describing what the network does if it doesn't like the client's choices.

Note that I am not arguing that the network operator cannot take action in
this case. I am, however, pretty convinced that it needs to remain out of
the discussions here for those discussions to actually deliver the bits the
group was chartered for.

Just my two cents, of course,

Ted

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Jul 2020 23:27:29 +0000

> Just my two cents, of course,

appreciated. if we provide a secure method of DNS server resource discovery to 
replace the known-unauthenticatable DHCP protocol previously used for this, we 
will create two new problems. perhaps that's ok, but it's avoidable.

new problem #1 is apps, devices, or users who don't speak this protocol or 
which don't agree to use the resources authentically offered on the local 
network. for privately-owned edge networks this may look like an attack, and 
they may take steps to defend against it.

new problem #2 is apps, devices, or users who face the defense noted in #1 and 
treat it ambiguously, as an "outage" of some kind, because there won't be a 
way for the local network to unambiguously signal "that's not allowed here."

so regardless of what the recently updated charter does not say, the job of 
authentically offering local DNS resources such as recursives or authorities 
will be incomplete if there's not a well defined (unambiguous) error path.

but i apologize for jumping ahead of the charter that's actually written down.

-- 
Paul

---

From: Ted Hardie <[email-masked]>
Date: Tue, 21 Jul 2020 16:59:05 -0700

> On Tuesday, 21 July 2020 23:10:51 UTC Ted Hardie wrote:

The job of authentically offering local DNS resources such as recursives or
> authorities  will be incomplete if there's not a well defined (unambiguous)
> error path.
>

I think some elements of that can fit within this:

Develop an informational document that describes mechanisms for
clients to detect specific network environments (such as captive portal
and split horizon) and to use that information to inform their DNS
configuration.

If the detected network environment has a set of resources that has no
intersection with the client's set of acceptable choices, then advice in
this document on how to surface that error would be useful.

That won't eliminate all calls to the helpdesk, but it can improve the
situation without changing what this has been set as deliverables.

regards,

Ted

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 22 Jul 2020 06:40:47 +0000

In-line.

On 7/21/20 12:42 PM, tirumal reddy wrote:
On Tue, 21 Jul 2020 at 06:13, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

Home routers are hardened (for example, see https://www.mind.be/openwrtsummit18/2018-10-30-OpenWRT18-prplWRT.html) to host network security services to protect the network from internal and external attacks.

Obviously some are better than others and we are constantly improving but it would be wrong to paint all of them with the same brush. The web servers that some of the CPE's host for management and configuration are awful to use and often insecure by design.

I currently have a few years old "enterprise-grade" CPE which allows me to broadcast 32 SSIDs but doesn't allow me to configure secrets that are longer than 8 alphanumeric characters.

--Mohit

-Ekr

[0] https://labs.bitdefender.com/2020/03/new-router-dns-hijacking-attacks-abuse-bitbucket-to-host-infostealer/

---

From: tirumal reddy <[email-masked]>
Date: Wed, 22 Jul 2020 13:24:50 +0530

Hi Tommy,

Please see inline

On Tue, 21 Jul 2020 at 21:05, Tommy Jensen <[email-masked]>
wrote:

> Hey Tiru,
>
> Thanks for sharing. In section 7 of your draft which defines the mechanism
> you’re proposing for PKI secures communication with an RFC1918 address, I
> see one problem:
>
> This depends on the DNS client already having “example.com” configured as
> a resolver. This doesn’t scale well. In order for a client to work out of
> the box with my ISP, it would need to come preconfigured with all known
> ISPs or provide a UX to add example.com as a resolver. The first doesn’t
> scale any better than pre-shared HOSTS files, and the second requires the
> user to get involved rather than providing security by default. While we
> are using a pre shared list today, it’s incredibly short and not a viable
> solution in the long term nor something I would want have as a requirement
> for mainstream consumer scenarios.
>

Yes, a pre-configured list of trusted resolvers is a short-term solution
and will not scale.

>
> One approach (which may be in your draft and I simply missed it) would be
> to make a connection to the parent of the DHCP/RA domain by dropping the
> leftmost labels and verify the certificate the same way. I would expect the
> CPE to provide the IP hint for that resolver as well. This at least would
> allow bootstrapping without any preconfiguration or user involvement needed
> unless I’m missing something?
>

Agreed, it works provided the domains and CPE are managed by the ISP and an
(out-of-band) agreement with the client to enable wild-card white-listing
for the ISP managed sub-domains. Please see
https://tools.ietf.org/html/draft-btw-add-home-07#section-7.1.2, it
discusses that a DoH/DoT client can learn the local DoH/DoT forwarder using
DHCP/RA and auto-upgrade because the left-most label of the pre-configured
ADN would match the subjectAltName value in the DNS server certificate.

> This should negate the need for the work described here requiring other
> token types for going from a DHCP message with novel server identifiers to
> a secure DNS connection to a local address.
>

I don't get the above line.

>
> > If the insecurely discovered DoH/DoT server is not pre-configured in
> the OS or browser, the client must validate the signatory (e.g.,
> cryptographically attested by the ISP [
> I-D.reddy-add-server-policy-selection
> <https://tools.ietf.org/html/draft-btw-add-home-07#ref-I-D.reddy-add-server-policy-selection>
> ]).
>

https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-03
discusses
how a DNS client can authenticate it is connecting to a DoH/DoT server hosted
by a specific organization (e.g., ISP). This information is
cryptographically signed to attest its authenticity. It is particularly
useful when the DoH/DoT server is insecurely discovered (e.g., using
DHP/RA) and prevents the client from connecting to an attacker's server. In
addition, the insecurely discovered ADN need not be pre-configured in the
client.

Cheers,
-Tiru

> *From:* Add <[email-masked]> on behalf of tirumal reddy <
> [email-masked]>
> *Sent:* Tuesday, July 21, 2020 3:32 AM
> *To:* Tommy Jensen <Jensen.Thomas=[email-masked]>
> *Cc:* Andrew Campling <[email-masked]>; [email-masked] <
> [email-masked]>; Eric Rescorla <[email-masked]>; Martin Thomson <
> [email-masked]>
> https://tools.ietf..org/html/draft-btw-add-home-07#section-7.1
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-btw-add-home-07%23section-7.1&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca9c32a64e4c2414a4bb508d82d6162d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309243589465652&sdata=ITEhDe%2FhKwhBMyLl5bFxJ3zns8la6KaUI%2FaoTH4MdzA%3D&reserved=0> for
> more details.
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-pauly-add-resolver-discovery-01%23section-5&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca9c32a64e4c2414a4bb508d82d6162d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309243589465652&sdata=FQHFqfeWey6sMwZbHz9o6Fk6ZF88QVE%2FC3ZayUwg8yE%3D&reserved=0>)
> try it with DoT without concern for hostname... Literally just add TLS SPAU
> attacks. https://tools.ietf.org/html/draft-btw-add-home-07#section-9
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-btw-add-home-07%23section-9&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca9c32a64e4c2414a4bb508d82d6162d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309243589465652&sdata=uXOEKmG0kIWFlDP%2BZpj%2FKVA3mlytZrW1wu4HlagbL40%3D&reserved=0> discusses
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca9c32a64e4c2414a4bb508d82d6162d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309243589475649&sdata=TJ3kxJ%2BwN7yvYs0j6zMHahyxDSH2Q%2BeKMUHzwaOTG2I%3D&reserved=0>
>
> --
> Add mailing list
> [email-masked]
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca9c32a64e4c2414a4bb508d82d6162d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309243589485641&sdata=UduP65SRKh5Y5vgz0Bgvp5zWt10MQN1UdvWXdaPlNJ0%3D&reserved=0>
>
>

---

From: tirumal reddy <[email-masked]>
Date: Wed, 22 Jul 2020 13:36:20 +0530

On Tue, 21 Jul 2020 at 17:59, Eric Rescorla <[email-masked]> wrote:

>> https://www.mind.be/openwrtsummit18/2018-10-30-OpenWRT18-prplWRT.html)
>> to host network security services to protect the network from internal and
>> external attacks.
>>
>

The attack in the link you posted is because the router management console
is using weak/default credentials. The attacker could bruteforce to guess
the credentials and change the DNS settings to deliver malware. Typical
network security services on home routers do check for weak/default
credentials on both routers and IoT devices, and prompt the user to change
the credentials. I see ISP deployments with both next-generation and legacy
routers.

Cheers,
-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Wed, 22 Jul 2020 14:45:20 +0530

On Tue, 21 Jul 2020 at 17:53, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> > The dprive WG would appear to be the right place for discussing
> encryption of DNS traffic. If you’re looking at end-to-end communications
> in general, that’s probably far too big and diffuse a topic to sit inside a
> single, all-encompassing tent.
>
> Well, RFC 7258 is the IETF's policy statement from which Tommy's question
> descends, so where was it discussed and approved at the time? That would
> look like an appropriate venue.
>
> By the way, the policy dimensions hit by that question are multiple and go
> way beyond the simple strive for encryption or for technical security. Some
> parties will prefer continuing to use the local resolver with encrypted
> DNS, even if discovered through a process which is only 99.99% secure,
> rather than switching to an open global resolver that can be authenticated
> with 100% certainty.

Secure discovery is possible in some scenarios like those discussed in
https://tools.ietf.org/html/draft-reddy-add-enterprise-00. In deployments
where secure discovery is not possible, client validation techniques like
pre-configured TRR or
cryptographic assertion of the server identity would ensure the client does
not connect to a DoT/DoH server hosted by a specific organization.

-Tiru

> I think that the IETF should provide the tools so that both things can
> happen easily, and then the decision on what to implement is likely to be
> non-technical and not driven by threat models (e.g. in Europe there
> currently are a lot of concerns and political debates about consolidation,
> competition and "self-preferencing" by the big platforms against local
> operators, so I wouldn't be surprised if this popped up there).
>
> --

---

From: tirumal reddy <[email-masked]>
Date: Wed, 22 Jul 2020 16:16:09 +0530

On Wed, 22 Jul 2020 at 04:24, Eric Rescorla <[email-masked]> wrote:

> A number of endpoints are using SPAU mechanisms for converting from Do53
> to Do[TH]. This draft points out that this has the potential to cause the

Several security vendors are offering network security services on CPE to
protect the home network from internal and external attacks (see
https://securehomeplatform.mcafee.com/, https://securingsam.com/), these
CPE are hardered and can host a DoH/DoT server. These CPE are already
deployed in several ISP deployments. I don't think it is a good idea to
exclude CPE from the design because of some legacy routers which anyway
cannot upgrade the firmware or have the capability to host a DoH/DoT server.

Cheers,
-Tiru

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 22 Jul 2020 13:59:53 +0200 (CEST)

> Il 21/07/2020 20:42 Tony Rutkowski <[email-masked]> ha scritto:
> 

Very interesting story - also considering Stephen's reply on how RFC 7258 was done without any specific process, I find more and more signs that the IETF for quite some years now has treaded recklessly into policy-intensive territories without giving any real thought at how to do it right :-) It would be interesting to have that discussion, but of course not here.

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 22 Jul 2020 08:48:53 -0400

Hi Vittorio,

An update.

The new head of the USDOJ antitrust investigations recently underscored 
the requirements for "importance of openness, balance, and transparency 
in standards development."  In addressing the enforcement activities, he 
notes that "without balancing interests of different members there is 
little value in a group having openness, due process, or an appeals 
process, as there would be no diversity of opinion that would leverage 
such principles into reaching consensus.”  The need for a "balance of 
interests," and not "restricting consumer choices" were underscored.

See at 
https://www.justice.gov/opa/speech/deputy-assistant-attorney-general-alexander-okuliar-delivers-remarks-intellectual

The record of RFC 7258 and its application to IETF work would seem to 
run afoul of these requirements and potentially expose the Trust and 
participants in the work to enforcement actions.  Almost all standards 
groups today have rather explicit antitrust conspiracy mitigation 
policies that are made incumbent on all participants in their ongoing 
collaborative activities.  Until those policies are established, these 
requirements are not actionable in add, even if they should be considered.

--tony

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jul 2020 09:17:09 -0400

On Jul 22, 2020, at 8:48 AM, Tony Rutkowski <[email-masked]> wrote:
> In addressing the enforcement activities, he notes that "without balancing interests of different members there is little value in a group having openness, due process, or an appeals process, as there would be no diversity of opinion that would leverage such principles into reaching consensus.”  The need for a "balance of interests," and not "restricting consumer choices" were underscored.

The IETF process is explicitly not “a balance of interests.” That’s what “we don’t believe in voting” means.

Rough consensus and running code means valuing technical arguments over majority preference. That’s why we have the process we do, and why we do not take votes.

You may not agree with this approach, but ADD is definitely not the place to be arguing about it.

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Wed, 22 Jul 2020 13:43:30 +0000

From the ADD Chairs-  

Everyone - Antitrust and SDO organization structure are out of scope for the ADD WG, please stop posting about it on this list.

Glenn Deen

> On Jul 22, 2020, at 5:49 AM, Tony Rutkowski <[email-masked]> wrote:
> 
> Hi Vittorio,
> 
> An update.
> 
> The new head of the USDOJ antitrust investigations recently underscored the requirements for "importance of openness, balance, and transparency in standards development."  In addressing the enforcement activities, he notes that "without balancing interests of different members there is little value in a group having openness, due process, or an appeals process, as there would be no diversity of opinion that would leverage such principles into reaching consensus.”  The need for a "balance of interests," and not "restricting consumer choices" were underscored.
> 
> See at https://urldefense.com/v3/__https://www.justice.gov/opa/speech/deputy-assistant-attorney-general-alexander-okuliar-delivers-remarks-intellectual__;!!PIZeeW5wscynRQ!6-ZZyRnBHzOahLnhVUAmgAd0CfGqd-baavM1yxsI7s11ADPaua0NOUVzffBp4V1t$ 
> The record of RFC 7258 and its application to IETF work would seem to run afoul of these requirements and potentially expose the Trust and participants in the work to enforcement actions.  Almost all standards groups today have rather explicit antitrust conspiracy mitigation policies that are made incumbent on all participants in their ongoing collaborative activities.  Until those policies are established, these requirements are not actionable in add, even if they should be considered.
> 
> --tony
> 
>>> https://urldefense.com/v3/__http://www.circleid.com/posts/20200711-addressing-anticompetitive-behaviur-in-internet-standards-bodies/__;!!PIZeeW5wscynRQ!6-ZZyRnBHzOahLnhVUAmgAd0CfGqd-baavM1yxsI7s11ADPaua0NOUVzfUgEsF9L$ 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/add__;!!PIZeeW5wscynRQ!6-ZZyRnBHzOahLnhVUAmgAd0CfGqd-baavM1yxsI7s11ADPaua0NOUVzfcgbJB0d$

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Jul 2020 15:11:44 +0000

From: Eric Rescorla <[email-masked]>
Sent: Tuesday, July 21, 2020 5:54 PM
To: STARK, BARBARA H <[email-masked]>
Cc: Michael Richardson <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] Practical Observations from Encrypted DNS Deployments by Network Operators

On Tue, Jul 21, 2020 at 3:41 PM STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
[BHS] While my ISP requires me to use the CE router they supply, I’ve never had an issue connecting that to my own router and then running my home network from my router. The CE router from my particular ISP (YMMV) even automatically passes on the public IPv4 address it acquires and a /64 IPv6 prefix to my router (so IPv4 just has the single NAT and IPv6 works great). I have total ability to choose any router I want and configure that router as much as that router vendor’s GUI allows (e.g., Netgear GUIs don’t let you configure the DNS server info it supplies to the LAN via DHCP, etc. – it always supplies its own IP address; it does let the user say whether its proxy will use DNS info it gets via DHCP or configure static DNS info). It seems to me that anyone who is concerned with what the ISP can do vis-à-vis their home network should be firewalling the ISP CE router, anyway. I’m at a loss to understand why people are considered “forced” to use the ISP CE router as their home network router, just because they’re forced to use it to terminate the ISP WAN connection. I do understand that people do this for ease and convenience. But those same people are also unlikely to care about changing away from the ISP resolvers. If you care enough to want to configure the DNS used in your home network, you should care enough to run your own router between your network and the ISP “WAN termination device”. --Barbara

I'm not quite sure what you're responding to here, because I didn't say anything about forced, and the concern I'm raising here is not about the ISP doing things vis-a-vis the user's home network but *attackers* doing things by compromising the ISP-provided CE router.

The context of this discussion as I understand it is this:
A number of endpoints are using SPAU mechanisms for converting from Do53 to Do[TH]. This draft points out that this has the potential to cause the endpoint to connect directly to the ISP's resolver, bypassing the CPE and any functions that the CPE performs (presumably the ISP resolver could perform some but not all of these) and proposes that we develop some mechanism to avoid bypassing the CPE. At least from my perspective this particular discussion is not about the ISP versus the consumer but about whether it is advisable to design a mechanism to keep the CPE in the loop.

-Ekr

[BHS] I’m going to assume that by “CPE” you’re referring to an ISP-supplied CE router in the context of this discussion. [Note: “CPE” is a general term that can mean any provider-supplied Customer Premises Equipment (e.g., routers, Wi-Fi extenders, set-top boxes, home security sensors and cameras) – although people occasionally use it to refer to any equipment on the customer’s premises; using “CPE” as synonymous with the (ISP-supplied) CE router is a pet peeve of mine.]  There had been a link provided earlier in this thread to a Linksys router vulnerability. Linksys has from time-to-time had deals with ISPs to supply routers, but most Linksys routers are not ISP-supplied (and therefore not CPE in the common definition of the term). Most Linksys routers are purchased by consumers. So I’m struggling to understand whether you believe that user-owned/installed applications and consumer host devices with a long track record of vulnerabilities should be avoiding services supplied by the home-network-owner owned/installed (and possibly compromised) CE routers (like Linksys) (independent of what the home-network-owner wants, because the vendors of highly-vulnerable and possibly compromised applications and host devices know what’s best); or that apps and devices should be avoiding services supplied by ISP-supplied/managed CE routers (which in the US tend to be frequently updated to address vulnerabilities).

Frequently, the first indication users have that their applications or host devices have been compromised is when the ISP tells them that viral traffic is coming from that home network (and the user’s Internet service may be suspended until it stops). The CE router is in the best position to detect malware emanating from the home network. We should be trying to make it easier for the CE router to do this, rather than more difficult.

And, BTW, by far the biggest vulnerabilities inside the home network are the users. What really seems to be implied is that the user can’t be trusted to do what is right for themselves, so applications and device vendors need to be in control and minimize users’ ability to automatically influence and control those apps and hosts (independent of whether users can or should trust the vendors; and who rarely have a contractual relationship with users). I disagree. While users are the biggest threat to their own home networks and devices, giving app and host vendors more control to bypass user and home-network-owner choices is not the answer. What we need is more and better tools for users and home-network-owners to know when something inside their network has been compromised and to make informed choices. -- Barbara

---

From: Paul Vixie <[email-masked]>
Date: Wed, 22 Jul 2020 20:17:06 +0000

> Very interesting story - also considering Stephen's reply on how RFC 7258
> was done without any specific process, I find more and more signs that the
> IETF for quite some years now has treaded recklessly into policy-intensive
> territories without giving any real thought at how to do it right :-) It
> would be interesting to have that discussion, ...

+1, noting that in my pre-pandemic world travels, i've met dozens if not 
hundreds of technologists capable of reasoning and working at the level 
required by IETF, and whose careers and other opportunities would be 
dramatically shifted by the outcomes of IETF, but who cannot afford the time 
or the travel to participate, or whose english language skills aren't at par. 
their general sense is that wealthy white people in silicon valley determine 
the future of the internet for reasons of ideology or business, and the rest 
of the world just goes along with those outcomes, having no practical 
alternatives. if this discussion is to be had, i'd like to know where and 
when.

> ... but of course not here.

also +1.

-- 
Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 Jul 2020 16:34:46 +0200

On Tue, Jul 21, 2020 at 07:14:47PM +0100,
 Neil Cook <[email-masked]> wrote 
 a message of 30 lines which said:

> People are free to choose their CPE.

This is not true in many cases (example: Orange, the biggest IAP in
France).

---

From: "Chris Box (BT)" <[email-masked]>
Date: Thu, 23 Jul 2020 17:50:15 +0100

Stephane,

EU's Network Neutrality regulation (
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32015R2120&rid=2#d1e445-1-1)
states:

1.   *End-users shall have the right to* access and distribute information
and content, use and provide applications and services, and *use terminal
equipment of their choice*, irrespective of the end-user’s or provider’s
location or the location, origin or destination of the information,
content, application or service, via their internet access service.

These have been in force for some years. If Orange don't let you change,
they are most likely in breach of the French law which adopts these
regulations.

Chris

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Jul 2020 16:28:12 +0200

On Thu, Jul 23, 2020 at 05:50:15PM +0100,
 Chris Box (BT) <[email-masked]> wrote 
 a message of 87 lines which said:

> These have been in force for some years. If Orange don't let you
> change, they are most likely in breach of the French law which
> adopts these regulations.

IANAL (and I don't know if you are) but I guess the problem is in the
definition of "terminal equipment of their choice". Some people may
claim it is the PC (or smartphone), and that the CPE is actually part
of the network, not a terminal equipment.

---

From: "Chris Box (BT)" <[email-masked]>
Date: Mon, 27 Jul 2020 17:49:21 +0100

I'm not a lawyer either, but as a designer of ISP services I need to
understand them. The rules are expanded by BEREC, as shown below.

25. Thirdly, end-users have the right to use terminal equipment of their
choice. Directive 2008/63/EC defines “terminal equipment” as “equipment
directly or indirectly connected to the interface of a public
telecommunication network”. The right to choose terminal equipment
therefore covers equipment which connects to the interface of the public
telecommunications network. This interface, the network termination point
(NTP)11, is defined in Article 2 (da) of the Framework Directive
(2002/21/EC),12 meaning the physical point at which a subscriber is
provided with access to a public communications network.
26. In considering whether end-users may use the terminal equipment of
their choice, NRAs should assess whether an ISP provides equipment for its
subscribers and restricts the end-users’ ability to replace that equipment
with their own equipment, i.e. whether it provides “obligatory equipment”.
27. Moreover, NRAs should consider whether there is an objective
technological necessity for the obligatory equipment to be considered as
part of the ISP network. If there is not, and if the choice of terminal
equipment is limited, the practice would be in conflict with the
Regulation. For example, the practice of restricting tethering is likely to
constitute a restriction on choice of terminal equipment because ISPs
“should not impose restrictions on the use of terminal equipment connecting
to the network in addition to those imposed by manufacturers or
distributors of terminal equipment in accordance with Union law” (Recital
5).

Source:
https://berec.europa.eu/eng/document_register/subject_matter/berec/regulatory_best_practices/guidelines/9277-berec-guidelines-on-the-implementation-of-the-open-internet-regulation