Subject: [Add] TR: I-D Action: draft-btw-add-home-07.txt

From: <[email-masked]>
Date: Wed, 15 Jul 2020 12:12:28 +0000

Hi all, 

We submitted an updated version of this spec with the following main changes:

* use the well-known URI to learn the supported services from the DHCP/RA discovered servers. 
* clarify that DHCP/RA discovered ADN takes precedence over special-use domain name.
* add a discussion to the Security Considerations section to cover some internal attacks. 

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 10 juillet 2020 15:58
À : [email-masked]
Objet : I-D Action: draft-btw-add-home-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Encrypted DNS Discovery and Deployment Considerations for Home Networks
        Authors         : Mohamed Boucadair
                          Tirumaleswar Reddy
                          Dan Wing
                          Neil Cook
	Filename        : draft-btw-add-home-07.txt
	Pages           : 25
	Date            : 2020-07-10

Abstract:
   This document discusses DoT/DoH deployment considerations for home
   networks.  It particularly sketches the required steps to use DoT/DoH
   capabilities provided by local networks.

   The document specifies new DHCP and Router Advertisement Options to
   convey a DNS Authentication Domain Name.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-btw-add-home/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-btw-add-home-07
https://datatracker.ietf.org/doc/html/draft-btw-add-home-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-btw-add-home-07

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

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: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Jul 2020 17:07:51 +0200

On Wed, Jul 15, 2020 at 12:12:28PM +0000,
 [email-masked] <[email-masked]> wrote 
 a message of 100 lines which said:

> * use the well-known URI to learn the supported services from the
> * DHCP/RA discovered servers.  clarify that DHCP/RA discovered ADN
> * takes precedence over special-use domain name.  add a discussion
> * to the Security Considerations section to cover some internal
> * attacks.

I just want to be sure I understand how the client is supposed to
discover the path in the DoH URL. If I get section 5 correctly, the
workflow is:
1) get the IP address of the DoH resolver, say 2008:db8:1::d0
2) request https://[2008:db8:1::d0]/.well-known/resinfo, which gives you
several URI templates
3) use one of the templates for the regular DoH requests.  Is that
correct?

Also, since today, few CAs allow certificates based on IP addresses,
the advice in section 4 "DoH/DoT servers SHOULD be located by their
address literals rather than their names" eliminates small DoE
resolvers and leave only the big ones, who can have (like Google and
Cloudflare) IP-based certificates.

Last thing, this proposal, like most (all?) ADD proposals is silent
about the risks of using the "default" (indicated by the access
network) resolver. If people need DoE, this is because they do not
trust this resolver, because it lies or because it logs (or
both). This deserves a warning. Section 9 mentions only the risks of a
third-party hijacking DHCP or a similar protocol, not the risks of the
default resolver, except in a limited way in the paragrapĥ "The use of
DoH/DoT also depends on the user's policies."

Speaking of this, the draft only mentions lying resolvers as providing
a (presumably useful) service (I quote: "ISPs use DNS to provide
additional services such as (but not limited to) malware filtering,
parental control, or VoD (Video on Demand) optimization." It should
mention censorship as well. At least add "ad blocking" in the list of
services <https://pi-hole.net/>.

(Personal opinion: I don't see the point of automatic discovery of a
secure resolver but it is a general ADD problem, not specific to this
draft.)

---

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

Hi Stéphane, 

Please see inline. 

Cheers,
Med

> De : Add [mailto:[email-masked]] De la part de Stephane
> Bortzmeyer
> Envoyé : lundi 20 juillet 2020 17:08
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : [email-masked]; ADD Mailing list ([email-masked])
> <[email-masked]>
> Objet : Re: [Add] TR: I-D Action: draft-btw-add-home-07.txt
> 
> discover the path in the DoH URL. If I get section 5 correctly,
> the workflow is:

[Med] ... and the authentication domain name (ADN).  

> 2) request https://[2008:db8:1::d0]/.well-known/resinfo, which
> gives you several URI templates

[Med] Given that we supply the ADN, the URI will look like: https://doh.example.com/.well-known/resinfo

> Also, since today, few CAs allow certificates based on IP

[Med] Indeed. This is captured in the draft: 

   As reported in Section 1.7.2 of [RFC6125]:

      "few certification authorities issue server certificates based on
      IP addresses, but preliminary evidence indicates that such
      certificates are a very small percentage (less than 1%) of issued
      certificates".

   In order to allow for PKIX-based authentication between a DNS client
   and a DoH/DoT server while accommodating the current best practices
   for issuing certificates, this document allows for configuring an
   authentication domain name to be presented as a reference identifier
   for DNS authentication purposes.

the advice in section 4 "DoH/DoT servers SHOULD be
> located by their address literals rather than their names"
> eliminates small DoE resolvers and leave only the big ones, who
> can have (like Google and

[Med] That is not the intent of that text. The recommendation is to supply a list of IP addresses (locators, if you will) in addition to the ADN to avoid a dependency on another resolver to resolve the name.

Please note that the sentence you quoted starts with "From an IP reachability standpoint, " and then followed by "This avoids
adding a dependency on another server to resolve the DoH/DoT name. "

> 
> Last thing, this proposal, like most (all?) ADD proposals is
> silent about the risks of using the "default" (indicated by the
> access
> trust this resolver, because it lies or because it logs (or both).
> This deserves a warning. Section 9 mentions only the risks of a
> third-party hijacking DHCP or a similar protocol, not the risks of
> the default resolver, except in a limited way in the paragrapĥ
> "The use of DoH/DoT also depends on the user's policies."

[Med] Actually, we have a full paragraph to cover this: 

   The use of DoH/DoT also depends on the user's policies.  For example,
   the user may indicate his/her consent to use (or not) the locally-
   discovered DoH/DoT server or request to review human-readable privacy
   policy information of a selected DNS server and to assess whether
   that DNS server performs DNS-based content filtering (e.g.,
   [I-D.reddy-add-server-policy-selection]).  The DNS client is assumed
   to adhere to these policies.  This document does not make any
   assumption about the structure of such policies nor mandates specific
   requirements.  Such policies and their handling is out of scope.

We wanted to avoid going too far in the "policy land", hence this wording. 

As of today's deployments, a user can override the configuration received from the network. We have a sentence for unmanaged CPEs: 

"override the DNS configuration it receives from the ISP-supplied"

We can add a similar one for managed CPEs.

> 
> Speaking of this, the draft only mentions lying resolvers as
> providing a (presumably useful) service (I quote: "ISPs use DNS to
> provide additional services such as (but not limited to) malware
> filtering, parental control, or VoD (Video on Demand)
> optimization." It should mention censorship as well. At least add
> "ad blocking" in the list of services <https://pi-hole.net/>.

[Med] That list is not exhaustive, but we can mention ad blocking. Thanks.

---

From: <[email-masked]>
Date: Wed, 22 Jul 2020 07:29:06 +0000

Hi Stéphane, 

I was about to update my local copy of the draft to address one of your comments, but I see that we do already have this text (see the last sentence, particular):

   Some ISPs rely upon external resolvers (e.g., outsourced service or
   public resolvers); these ISPs provide their customers with the IP
   addresses of these resolvers.  These addresses are typically
   configured on CPEs using the same mechanisms listed above.  Likewise,
   users can modify the default DNS configuration of their CPEs (e.g.,
   supplied by their ISP) to configure their favorite DNS servers.  This
   document permits such deployments.

Cheers,
Med

> > Bortzmeyer Envoyé : lundi 20 juillet 2020 17:08 À : BOUCADAIR
> Mohamed
> > TGI/OLN <[email-masked]> Cc :
> > [email-masked]; ADD Mailing list ([email-masked])
> > <[email-masked]> Objet : Re: [Add] TR: I-D Action:
> > draft-btw-add-home-07.txt
> >
> >
> the
> As of today's deployments, a user can override the configuration
> received from the network. We have a sentence for unmanaged CPEs:
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 22 Jul 2020 16:16:07 -0400

> > De : Add [mailto:[email-masked]] De la part de Stephane
...

> [Med] That is not the intent of that text. The recommendation is to supply
> a list of IP addresses (locators, if you will) in addition to the ADN to
> avoid a dependency on another resolver to resolve the name.
>
> Please note that the sentence you quoted starts with "From an IP
> reachability standpoint, " and then followed by "This avoids

I read this text similarly to Stephane.  Are you saying that the resolver
IP addresses in the same RA/DHCP message should be the IP addresses that
serve the ADN?  What if they are not?  Or what if there are multiple ADNs?
What is the client supposed to do?

> We wanted to avoid going too far in the "policy land", hence this wording.

This draft is already way too deep in "policy land".  Most of Section 1,
and much of Section 3, is dedicated to advancing a thesis about resolver
selection policy, which is out of scope for this working group.  Please
remove these claims.

I would also recommend removing this quoted text from Section 9.  There's
no need to spend time on anybody's policies; the drafts should focus on the
technical mechanisms and leave policy out of it.

---

From: <[email-masked]>
Date: Thu, 23 Jul 2020 08:42:22 +0000

Hi Ben,

Please see inline.

Cheers,
Med

De : Ben Schwartz [mailto:[email-masked]]
Envoyé : mercredi 22 juillet 2020 22:16
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : Stephane Bortzmeyer <[email-masked]>; [email-masked]; ADD Mailing list ([email-masked]) <[email-masked]>
Objet : Re: [Add] TR: I-D Action: draft-btw-add-home-07.txt

On Tue, Jul 21, 2020 at 4:45 AM <[email-masked]<mailto:[email-masked]>> wrote:

> De : Add [mailto:[email-masked]<mailto:[email-masked]>] De la part de Stephane
> Bortzmeyer
...

I read this text similarly to Stephane.

[Med] OK. Please note that the text talks about “located” not “identified”. Anyway, will see how to make that text better.

  Are you saying that the resolver IP addresses in the same RA/DHCP message should be the IP addresses that serve the ADN?

[Med] The current proposal is to leverage RFC2132/RFC3646/RFC8106. For example, a DHCPv6 client that asks for encrypted DNS servers should include OPTION_DNS_SERVERS in its request as well. An alternate design is to define the new options to carry both the ADN and a list of IP addresses. This alternate design has implications on the size of the messages if the client requests Do53 and one or more encrypted DNS that happen to terminate all the on the same IP address(es). Which design to pick is up to the WG.

  What if they are not?
[Med] The server will return a list of @es if requested by the client. If the client does not ask for the OPTION_DNS_SERVERS, this means that client is able to resolve the ADN by passing it to a resolution library.

Or what if there are multiple ADNs?
[Med] If there are multiple ADNs but terminate on distinct IP@es, multiple addresses will be included. We use to have an appendix explaining this behaviour (https://tools.ietf.org/html/draft-btw-add-home-03#appendix-A). The main story is that the server will return a “customized” list of IP addresses as a function of the requested encrypted DNS. If, for example, DoT is reachable at @1 and DoH in @2, the server will return both @1 and @2 for a client requesting both DoT and DoH.

  What is the client supposed to do?
[Med] The DoT client will go through the @ list returned by the server and will succeed to establish a session with @1. The DoH client will do the same but will conclude that @2 is responsive and will establish a DoH session with @2.

This draft is already way too deep in "policy land".  Most of Section 1, and much of Section 3, is dedicated to advancing a thesis about resolver selection policy, which is out of scope for this working group.  Please remove these claims.

[Med] Will double check if there are “policy claims” in these sections and remove them.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 23 Jul 2020 10:58:45 -0400

On Thu, Jul 23, 2020 at 4:42 AM <[email-masked]> wrote:

> Hi Ben,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Ben Schwartz [mailto:[email-masked]]
> *Envoyé :* mercredi 22 juillet 2020 22:16
> *À :* BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> *Cc :* Stephane Bortzmeyer <[email-masked]>;
> [email-masked]; ADD Mailing list ([email-masked]) <[email-masked]
> >
> *Objet :* Re: [Add] TR: I-D Action: draft-btw-add-home-07.txt
>
>
>
>
>
>
>
> [Med] OK. Please note that the text talks about “located” not
> “identified”. Anyway, will see how to make that text better.
>
>
>
>   Are you saying that the resolver IP addresses in the same RA/DHCP
> message should be the IP addresses that serve the ADN?
>
>
>
> [Med] The current proposal is to leverage RFC2132/RFC3646/RFC8106. For
> example, a DHCPv6 client that asks for encrypted DNS servers should include
> OPTION_DNS_SERVERS in its request as well. An alternate design is to define
> the new options to carry both the ADN and a list of IP addresses. This
> alternate design has implications on the size of the messages if the client
> requests Do53 and one or more encrypted DNS that happen to terminate all
> the on the same IP address(es). Which design to pick is up to the WG.
>
>
>
>   What if they are not?
>
> [Med] The server will return a list of @es if requested by the client. If
> the client does not ask for the OPTION_DNS_SERVERS, this means that client
> is able to resolve the ADN by passing it to a resolution library.
>

And where is this resolution library supposed to send its queries?  Are you
proposing that the client run its own full recursive?

>
> [Med] If there are multiple ADNs but terminate on distinct IP@es,
> multiple addresses will be included. We use to have an appendix explaining
> this behaviour (
> https://tools.ietf.org/html/draft-btw-add-home-03#appendix-A). The main
> story is that the server will return a “customized” list of IP addresses as
> a function of the requested encrypted DNS. If, for example, DoT is
> reachable at @1 and DoH in @2, the server will return both @1 and @2 for a
> client requesting both DoT and DoH.
>
>
>
>
>
> [Med] The DoT client will go through the @ list returned by the server and
> will succeed to establish a session with @1. The DoH client will do the
> same but will conclude that @2 is responsive and will establish a DoH
> session with @2.
>

OK, so clients are expected to try every combination of ADN/protocol and IP
until they find a pair that works.  This seems like an inefficiency that we
should be able to avoid.  For example, we could allow multiple
OPTION_DNS_SERVERS, assign each one an index (e.g. in order of appearance),
and refer to it by index in the TBA2 option.

---

From: <[email-masked]>
Date: Fri, 24 Jul 2020 13:48:59 +0000

Hi Ben,

Please see inline.

Cheers,
Med

Envoyé : jeudi 23 juillet 2020 16:59

On Thu, Jul 23, 2020 at 4:42 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ben,

Please see inline.

Cheers,
Med

De : Ben Schwartz [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mercredi 22 juillet 2020 22:16
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>
Cc : Stephane Bortzmeyer <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; ADD Mailing list ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Add] TR: I-D Action: draft-btw-add-home-07.txt

...

  What if they are not?

And where is this resolution library supposed to send its queries?

[Med] It depends on the resolution library, see for example the list in https://datatracker.ietf.org/doc/html/rfc6055#section-1. The assumption is: if a client does not ask for OPTION_DNS_SERVERS, this means that the client is able to resolve the name, otherwise it should requested OPTION_DNS_SERVERS as well.

  Are you proposing that the client run its own full recursive?

OK, so clients are expected to try every combination of ADN/protocol and IP until they find a pair that works.

[Med] Yes. Note that behavior will be needed anyway to accommodate: dual-stack (IPv4/IPv6) clients or the failure of the primary DNS server and fall back to a secondary one.

  This seems like an inefficiency that we should be able to avoid.  For example, we could allow multiple OPTION_DNS_SERVERS, assign each one an index (e.g. in order of appearance), and refer to it by index in the TBA2 option.

[Med] If we think that it is likely that more deployments will be based on distinct IP@es, the simple approach is to encode both the ADN and the list in the same option. Relying on an index will create a dependency on how the ADN and OPTION_DNS_SERVERS will be populated.