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

From: <[email-masked]>
Date: Wed, 4 Mar 2020 09:52:14 +0000

Hi all, 

We submitted this new I-D.

Comments and suggestions are welcome.

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 4 mars 2020 09:09
À : [email-masked]
Objet : I-D Action: draft-btw-add-home-00.txt

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

        Title           : DoH/DoT Deployment Considerations for Home Networks
        Authors         : Mohamed Boucadair
                          Tirumaleswar Reddy
                          Dan Wing
	Filename        : draft-btw-add-home-00.txt
	Pages           : 17
	Date            : 2020-03-04

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.

   One of the goals of this document is to assess to what extent
   existing tools can be used to provide a DoT/DoH service.  As an
   outcome, new DHCP and Router Advertisement Options are specified in
   order 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-00
https://datatracker.ietf.org/doc/html/draft-btw-add-home-00

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

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 6 Mar 2020 18:02:42 +0000

Hey Med,

Thanks for sharing. Based on Section 10, it seems the intent of this draft is to ensure use of DoT/DoH servers is prohibited until the user sees and agrees to a privacy policy (exception: the device is configured ahead of time by an admin to trust the given server). Is that accurate?

If this is the case, I would be opposed to this version of the draft. While I agree users and admins should have more control over their DNS queries, blocking Internet access on DNS server approval for home users (with no enterprise admin to do the hard work for them) seems like a deal breaker for OS vendors. I wouldn't block an HTTPS connection until the user reviews the certificate chain either. Having this information available to decorate Internet connection UI seems wise but blocking connectivity on approval is too heavy handed for the general use case for OSes.

Other feedback:

  *   I see you're using "Do53" and referring to RFC8499. That RFC doesn't specify whether "Do53" or "classic DNS" or something else is the appropriate term. There is a draft<https://tools.ietf.org/html/draft-hoffman-dns-terminology-ter-02> to address this by defining "classic DNS" but it expired. Probably time for us to revisit that and formalize a term we can all use.

  *   Section 1:
     *   s/sotrage/storage
     *   s/resolexpervers/resolvers

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Wednesday, March 4, 2020 1:52 AM
To: ADD Mailing list <[email-masked]>
Cc: Konda, Tirumaleswar Reddy ([email-masked]) <[email-masked]>; Dan Wing <[email-masked]> ([email-masked]) <[email-masked]>
Subject: [EXTERNAL] [Add] TR: I-D Action: draft-btw-add-home-00.txt

Hi all,

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 4 mars 2020 09:09
À : [email-masked]
Objet : I-D Action: draft-btw-add-home-00.txt

Abstract:

The IETF datatracker status page for this draft is:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-btw-add-home%2F&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C5f21d93bdb3949ebf5d608d7c021c80a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189123649108842&amp;sdata=F8pys3zEoy0vOGnOgT78LOJIbKzaNlMgtDconAJ2hLQ%3D&amp;reserved=0

There are also htmlized versions available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-btw-add-home-00&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C5f21d93bdb3949ebf5d608d7c021c80a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189123649108842&amp;sdata=EhFMoMg65FtPOpz2IJTWO%2BsYDL178RA75fjy7V2yHI0%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-btw-add-home-00&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C5f21d93bdb3949ebf5d608d7c021c80a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189123649108842&amp;sdata=758uOmwdnh7QdcYVc4HtGgbeMIFHuLjtMp7wFsdS1mE%3D&amp;reserved=0

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announce&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C5f21d93bdb3949ebf5d608d7c021c80a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189123649108842&amp;sdata=oLdsbny2vjhDliNJRVwM3r%2FpRXlUIlApOwf7cz2Snho%3D&amp;reserved=0
Internet-Draft directories: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.org%2Fshadow.html&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C5f21d93bdb3949ebf5d608d7c021c80a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189123649108842&amp;sdata=fiRJ58jcj7gEilNpexiWBmXpiIWPdj11WgqbIESfhSg%3D&amp;reserved=0
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7C5f21d93bdb3949ebf5d608d7c021c80a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189123649108842&amp;sdata=a8stqwwalz8Cvab2vjAurTftzQfuiwhOqYSy048prJw%3D&amp;reserved=0

---

From: <[email-masked]>
Date: Sat, 7 Mar 2020 17:18:09 +0000

Hi Tommy,

Thank you for the comments.

Please see inline.

Cheers,
Med

De : Tommy Jensen [mailto:[email-masked]]
Envoyé : vendredi 6 mars 2020 19:03
À : BOUCADAIR Mohamed TGI/OLN; ADD Mailing list
Cc : Konda, Tirumaleswar Reddy ([email-masked]); Dan Wing <[email-masked]> ([email-masked])
Objet : Re: I-D Action: draft-btw-add-home-00.txt

Hey Med,

Thanks for sharing. Based on Section 10,
[Med] I guess you meant the Security section.

it seems the intent of this draft is to ensure use of DoT/DoH servers is prohibited until the user sees and agrees to a privacy policy (exception: the device is configured ahead of time by an admin to trust the given server). Is that accurate?

[Med] The draft discusses many options under which the DNS client auto-upgrades to use a discovered local DoH/DoT server without seeking for the user consent, but we have one particular case (called out in the security considerations Section) in which some 'input' is required to avoid a misuse of the service. That input can be a global configuration parameter, an explicit consent, a default, etc.

We need collectively to think about the exact behavior to follow. For example, it does not make sense to seek for the user consent to upgrade to DoT/DoH while that same server is used for Do53.

Other feedback:

  *   I see you're using "Do53" and referring to RFC8499. That RFC doesn't specify whether "Do53" or "classic DNS" or something else is the appropriate term. There is a draft<https://tools.ietf.org/html/draft-hoffman-dns-terminology-ter-02> to address this by defining "classic DNS" but it expired. Probably time for us to revisit that and formalize a term we can all use.
[Med] Agree Do53 is not defined in RFC8499. It is defined in the dnsop I-D cited in Section 2.
   This document makes use of the terms defined in [RFC8499<https://tools.ietf.org/html/rfc8499>] and
  [I-D.ietf-dnsop-terminology-ter<https://tools.ietf.org/html/draft-btw-add-home-01#ref-I-D.ietf-dnsop-terminology-ter>].
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  *   Section 1:

     *   s/sotrage/storage
     *   s/resolexpervers/resolvers
[Med] Thank you for catching those. We have already fixed them in -01: https://tools.ietf.org/html/draft-btw-add-home.
Thanks,
Tommy

Hi all,

Cheers,
Med

-----Message d'origine-----
De : I-D-Announce [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 4 mars 2020 09:09
À : [email-masked]
Objet : I-D Action: draft-btw-add-home-00.txt

Abstract:

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 09 Mar 2020 10:37:15 +1100

This seems very similar to draft-peterson-doh-dhcp and draft-peterson-dot-dhcp.  It claims to address both, but the mechanism is identical to the DoT piece.  There is a bunch more meat to the draft that I appreciate in terms of setting context.

How do you anticipate DoH servers being located using this?  I don't see any way you could acquire the URI template using the provided options.

On Wed, Mar 4, 2020, at 20:52, [email-masked] wrote:
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 9 Mar 2020 00:17:43 +0000

Hiya,

> We submitted this new I-D.

I read the -00 and just scanned the diff to -01.

I'm not sure this is the right approach. It's worth
talking about though.

Aside from issues already raised, (with which I might
end up agreeing, not sure yet), I have one major issue
with the draft...

I have a home router that uses DoT (as a forwarder)
to a server I configured. (Actually I also operate the
server but that's beside the point:-) Since I set that
up, later releases of the router OS (Turris) ship with
DoT server configs that can be chosen via GUI on the
router. Not sure if they have a DoH option, but there's
no reason that couldn't be added. None of that involves
my ISP. None of that needs to. I don't think that model
is envisaged in the draft text, at least as I read it.
I think it should be, as that architectural component
(home router or server or g/w that's not owned by ISP
nor by other mega-company but that exists to do the
home n/w owner's bidding) is, I think, important to
support well.

I do get that, today, such setups are rare. But we
should still support 'em, because they do allow for
better service to home n/w users, even if the much
more likely defaults are less optimal in that respect.

Cheers,
S.

---

From: <[email-masked]>
Date: Mon, 9 Mar 2020 12:03:51 +0000

Hi Martin,

Good point about the URI template. The draft already includes the following:

   If DoH is supported by the DNS server, the DNS client may request the
   URI resource record type [RFC7553] using the domain name discovered
   using DNS Reference Identifier DHCP/RA option (Section 4) to use the
   HTTPS URI scheme (Section 3 of [RFC8484]).

Other methods such as draft-ietf-dnsop-resolver-information can be considered as well. 

Wouldn't that be sufficient? 

Thank you.

Cheers,
Med

> De : Add [mailto:[email-masked]] De la part de Martin Thomson
> Envoyé : lundi 9 mars 2020 00:37
> À : [email-masked]
> Objet : Re: [Add] TR: I-D Action: draft-btw-add-home-00.txt
> 
> This seems very similar to draft-peterson-doh-dhcp and draft-peterson-
> dot-dhcp.  It claims to address both, but the mechanism is identical
> to the DoT piece.  There is a bunch more meat to the draft that I
> appreciate in terms of setting context.
> 
> How do you anticipate DoH servers being located using this?  I don't
> see any way you could acquire the URI template using the provided
> options.
> 
> > De : I-D-Announce [mailto:[email-masked]] De la part
> de
> > [email-masked]

---

From: <[email-masked]>
Date: Mon, 9 Mar 2020 12:28:26 +0000

Hi Stephen,

Please see inline.

Cheers,
Med

> De : Stephen Farrell [mailto:[email-masked]]
> Envoyé : lundi 9 mars 2020 01:18
> Cc : Konda, Tirumaleswar Reddy ([email-masked]);
> Dan Wing <[email-masked]> ([email-masked])

[Med] FYI, -02 is available at: https://tools.ietf.org/html/draft-btw-add-home-02 

> I'm not sure this is the right approach. It's worth talking about
> though.
> 
> Aside from issues already raised,

[Med] Which issues are you referring to?

 (with which I might end up agreeing,
> not sure yet), I have one major issue with the draft...
> 
> I have a home router that uses DoT (as a forwarder) to a server I
> configured. (Actually I also operate the server but that's beside the
> point:-) Since I set that up, later releases of the router OS (Turris)
> ship with DoT server configs that can be chosen via GUI on the router.
> Not sure if they have a DoH option, but there's no reason that
> couldn't be added. None of that involves my ISP.

[Med] The scenario where the default CPE configuration is modified by a user to point to a 3d part DNS server is supported in the draft. Such scenario does not involve the ISP. The ADN and the IP addresses of the 3rd party server will be announced by the CPE to internal hosts. Typically, a DNS client will switch to DoT if the third party server is a verified server. 

                      ,--,--,--.             ,--,--,--.
        DoT-capable ,-'          `-.       ,-' 3rd Party `-.
          Host----(      LAN      CPE----(    DNS Server  )
             |     `-.          ,-'|      `-.          ,-'
             |        `--'--'--'   |         `--'--'--'
             |<===DHCP(ADN,@)=====>|             | 
             |                                   |
             |<================DoT/DoH==========>|

 None of that needs
> to. I don't think that model is envisaged in the draft text, at least
> as I read it.
> I think it should be, as that architectural component (home router or
> server or g/w that's not owned by ISP nor by other mega-company but
> that exists to do the home n/w owner's bidding) is, I think, important
> to support well.

[Med] Your scenario would look like the following: 

                      ,--,--,--.             ,--,--,--.
        DoT-capable ,-'          `-.       ,-' 3rd Party `-.
          Host----(      LAN      CPE----(    DNS Server  )
             |     `-.          ,-'|      `-.          ,-'
             |        `--'--'--'   |         `--'--'--'
             |                     |             | 
             |<======DoT/DoH======>|<==DoT/DoH==>|

Before answering whether this case is covered in the current version of the draft, can you please clarify which setup actions do you perform (including on the CPE and the host)? E.g., Do you get a domain name? Do you make use of certificates? Thank you.

> 
> I do get that, today, such setups are rare. But we should still
> support 'em, because they do allow for better service to home n/w
> users, even if the much more likely defaults are less optimal in that
> respect.
> 
> Cheers,
> S.
> 
> 
> 
> 
> 
> >
> > [email-masked] Envoyé : mercredi 4 mars 2020 09:09 À :
> > [email-masked] Objet : I-D Action: draft-btw-add-home-00.txt
> >
> >
> > 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-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 9 Mar 2020 13:05:52 +0000

Hiya,

> [Med] Your scenario would look like the following: 

Not quite that. Sorry for the absence of ascii-art but
the CPE provided by the ISP is not the DoT-enabled home
router in my case - I have a 2nd router inside the home
n/w  (from the POV of the ISP's CPE). The devices inside
the home n/w (other than a couple of oddities) use that
2nd router and today do Do53 to that. There are also
some devices that use DoH or Dot to CF or other places
I've configured.

> Before answering whether this case is covered in the current version of the draft, can you please clarify which setup actions do you perform (including on the CPE and the host)? E.g., Do you get a…

In my setup all the certs are verifiable chaining up
to the usual browser root stores.

But my main comment is that the home router that does
almost all DNS might not be provided by the ISP so any
discovery or similar protocol ought not make that
assumption. I recognise that that's a corner-case and
it may remain so, but equally, home networks might
develop in other directions due to a plethora of
small devices unrelated to the ISP, so we should
keep that kind of setup in mind.

Cheers,
S.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 10 Mar 2020 12:02:22 +1100

>    HTTPS URI scheme (Section 3 of [RFC8484]).

I missed that, thanks.

A URI template is not a URI, so that's a little odd.  But that's just semantics, I'm happy to wave that aside if others are.

A more substantive concern is that this creates a false equivalence between domain name and DoH service.  You can only ever have one DoH service for a given host if you choose this mechanism.  Using DNS like this means that the choice is made for the name as a whole and not as part of the proposed host configuration.  For me, I'd prefer something more explicit in the RA/DHCP/etc...

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 10 Mar 2020 10:59:57 +0100 (CET)

> Il 09/03/2020 14:05 Stephen Farrell <[email-masked]> ha scritto:
> 
> assumption. I recognise that that's a corner-case 

Yes, it's an infrequent case, but I would not call it a corner case. At least in Europe, there is regulation that requires all ISPs to allow users to buy and deploy any CPE they like. Also, it is relatively common, for smart users that couldn't get their ISP to do without the CPE, to deploy another router in front (LAN-side) of the CPE. This happens, for example, because the CPE has the appropriate fiber termination but the user's desired home router has not, but has other features that the user needs. So indeed these are use cases that have to be supported.

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

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 10 Mar 2020 11:18:42 +0100 (CET)

>     Il 07/03/2020 18:18 [email-masked] ha scritto:
> 
> 
I agree, though "user consent" is generic. If we suggest that as a best practice consent should be asked, we should make it explicit why, and what should the user be consenting to.

If user consent is introduced to comply with data protection laws, then the elements of the consent are:
- who will get the data
- what will that party do with the data
This means that the transmission channel over which data is sent to that party is unimportant in terms of consent, so if the user is ok with the DNS operator receiving their information via Do53, it can be assumed that he/she is also ok with the DNS operator receiving the same information via DoT/DoH or in any other way.

On the other hand, if the consent is tied to the degree of channel security that is offered, then indeed the switch of channel might affect the user's desire to consent. Still, if we can assume that DoT/DoH towards the same operator always offers more security than Do53, and that the user has already consented to Do53, then we can also assume that the user will be happy with DoT/DoH as well.

Bottom line: if we want to discuss consent-related issues in a draft, we should expand the reasons behind our suggestions. Or we can just strike the discussion entirely, as apparently it has been done in the last versions.

--

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

---

From: "Ian Maddison" <[email-masked]>
Date: Tue, 10 Mar 2020 12:08:12 +0100

Hi Vittorio,

> On the other hand, if the consent is tied to the degree of channel security that is offered, then indeed the switch of channel might affect the user's desire to consent. Still, if we can assume tha…

That sounds fine until you consider the probable DNS performance degradation of DoT/DoH compared to Do53. Perhaps users prefer to give prior consent to anything that affects their performance. Apologies if this isn't currently in scope, but nonetheless I feel it would be wise to also consider DNS performance aspects here.

---

From: <[email-masked]>
Date: Tue, 10 Mar 2020 12:58:53 +0000

Hi Martin,

Defining an RA/DHCP option to achieve what you are describing is feasible but we need to think about the overall model before we go that path. 

(1) For example, the domain name provided in RA/DHCP will be used to retrieve supported DoH services following methods such as those in draft-ietf-doh-resolver-associated-doh. I see some advantages in restricting the information to be conveyed by the network to a domain name and a of IP addresses as we don't need a change to the network configuration to reflect a change of DoH services. 

This is less of a concern for DHCP but may be problematic for RAs (risk of stale information). Of course things can be automated but I think that we need to discuss these details.

(2) RFC8484 defines only a single variable "dns" but future specs can define other URI templates with other variables: How validation will be done by DHCP clients? Or should DHCP clients "blindly" pass that templates to DoH clients that will proceed with the validation?

Thoughts?

Cheers,
Med

> De : Martin Thomson [mailto:[email-masked]]
> Envoyé : mardi 10 mars 2020 02:02
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> A URI template is not a URI, so that's a little odd.  But that's just
> semantics, I'm happy to wave that aside if others are.
> 
> A more substantive concern is that this creates a false equivalence
> between domain name and DoH service.  You can only ever have one DoH
> service for a given host if you choose this mechanism.  Using DNS like
> this means that the choice is made for the name as a whole and not as
> part of the proposed host configuration.  For me, I'd prefer something
> more explicit in the RA/DHCP/etc...

---

From: <[email-masked]>
Date: Tue, 10 Mar 2020 13:21:18 +0000

Hi Ian, Vittorio,

What you are both saying is exactly why handling user consent is a more general point, not specific to this draft.

That is why we went with the following in the draft:

   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 to assess whether that

   DNS server performs DNS-based content filtering (e.g.,

   [I-D.reddy-dprive-dprive-privacy-policy<https://tools.ietf.org/html/draft-btw-add-home-03#ref-I-D.reddy-dprive-dprive-privacy-policy>]).  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.

Cheers,
Med

De : Add [mailto:[email-masked]] De la part de Ian Maddison
Envoyé : mardi 10 mars 2020 12:08
À : Vittorio Bertola; ADD Mailing list
Objet : Re: [Add] I-D Action: draft-btw-add-home-00.txt

Hi Vittorio,

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 10 Mar 2020 14:31:23 +0100 (CET)

>     Il 10/03/2020 14:21 [email-masked] ha scritto:
> 
> 
> 
>     Hi Ian, Vittorio,
> 
>      
> 
I was actually wondering whether a non-technical draft devoted to framing and discussing issues of consent and privacy in the selection of DNS resolvers, as part of the third point of the charter, would be useful - or whether it would just prompt circular talk. In case, it should be written by/with policy people and privacy experts (there are several in DPRIVE and HRPC already).

--

---

From: Andrew Campling <[email-masked]>
Date: Tue, 10 Mar 2020 14:05:05 +0000

On Tues, 10 Mar, 2020, at 13:31, Vittorio Bertola <[email-masked]> wrote:

>  I was actually wondering whether a non-technical draft devoted to framing and discussing issues of
>  consent and privacy in the selection of DNS resolvers, as part of the third point of the charter, would
>  be useful - or whether it would just prompt circular talk. In case, it should be written by/with policy
>  people and privacy experts (there are several in DPRIVE and HRPC already).

In my view such a document would indeed be useful but would be out of scope for the ADD charter so would need to find a home elsewhere – no doubt others will comment on whether this should be within or outside of the IETF.  Such a document would of course need to account for local legislative requirements such as GDPR, CCPA etc, for example noting that if consent is sought under GDPR it must be opt-in, cannot be opt-out.

Andrew

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2020 14:30:31 +0000

On 10/03/2020 13:31, Vittorio Bertola wrote:
> I was actually wondering whether a non-technical draft devoted to
> framing and discussing issues of consent ... in the selection
> of DNS resolvers,

I think that's a terrible idea. It'd be pointless because
there is no meaningful consent involved - if people do not
know that the DNS exists they cannot reasonably be asked
for any real consent about it. This kind of fiction is used
by organisations of all kinds in the tech industry
generally and the web to fool users and nothing else (IMO).

See also Steve Bellovin's recent IETF plenary talk on why
all the "consent" stuff is nonsensical.

I do think there could be scope for an IETF document that
says "people can't consent to things they don't understand
about the Internet" and that could even be a useful BCP
("IETF specifications MUST NOT discuss user consent as that
is fictional because..."). However I doubt we'd get rough
consensus for that. (It's tempting to try though:-) And
that's definitely not in scope for this WG.

(I elided "and privacy" in my quote from Vittorio above,
because documenting those issues seems fine to me.)

Cheers,
S.

---

From: Andrew Campling <[email-masked]>
Date: Tue, 10 Mar 2020 14:50:39 +0000

On 10/03/2020 14:31, Stephen Farrell <[email-masked]> wrote:

>  I think that's a terrible idea. It'd be pointless because there is no meaningful consent
>  involved - if people do not know that the DNS exists they cannot reasonably be asked
>  for any real consent about it. This kind of fiction is used by organisations of all kinds in
>  the tech industry generally and the web to fool users and nothing else (IMO).
>
>  See also Steve Bellovin's recent IETF plenary talk on why all the "consent" stuff is
>  nonsensical.

Whilst I agree that consent can be used as a smokescreen, just because it may not be easy doesn't mean that it isn't possible to do properly nor that it shouldn't be done – and of course the ultimate decision does not rest with the tech industry anyway.  Regulators tell me that, under GDPR, they do consider DNS data to be personally identifiable data.  If consent isn’t sought to process personal data there are other lawful bases that are available, for example if the processing is required for a legitimate interest of the data controller.  However this must be balanced with the legitimate interests of the individual and the data controller will need to be prepared to justify their choice to the regulator if challenged.

Andrew

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Mar 2020 16:05:19 +1100

On Tue, Mar 10, 2020, at 23:58, [email-masked] wrote:
> (1) For example, the domain name provided in RA/DHCP will be used to 
> retrieve supported DoH services following methods such as those in 
> draft-ietf-doh-resolver-associated-doh.

I note that you proposed yet another method for resolution in addition to the three in that document.  Given the plethora of options we have, with no principles driving our decision-making process, it might be time for us to collectively determine what those principles might be.

> I see some advantages in 
> restricting the information to be conveyed by the network to a domain 
> name and a of IP addresses as we don't need a change to the network 
> configuration to reflect a change of DoH services. 

I see only the disadvantages inherent in splitting the configuration between different domains.

I know that grovelling around in DHCP/RA can be a nightmare (especially for ISPs who might be faced with outdated CPE), but once you accept the need to do that, it's not that much harder to ensure all the configuration is there.  Besides, you shouldn't need to change the URL often: https://www.w3.org/Provider/Style/URI

> (2) RFC8484 defines only a single variable "dns" but future specs can 
> define other URI templates with other variables: How validation will be 
> done by DHCP clients? Or should DHCP clients "blindly" pass that 
> templates to DoH clients that will proceed with the validation?

I think that can easy.  URI templates generally tolerate the addition of new field well.  If someone adds {?disable-dnssec} to the template and you don't know how to generate that, then you don't need to add it and everything works out.  You can build templates that don't work in the presence of extensions, but that is something we can manage as we add extensions.

---

From: Erik Kline <[email-masked]>
Date: Tue, 10 Mar 2020 23:28:03 -0700

On Tue, Mar 10, 2020 at 10:05 PM Martin Thomson <[email-masked]> wrote:

> I note that you proposed yet another method for resolution in addition to
> the three in that document.  Given the plethora of options we have, with no
> principles driving our decision-making process, it might be time for us to
> collectively determine what those principles might be.
>

Without even trying to be complete, I'd offer that requirements should
probably include:

    * allowing clients to bootstrap to encrypted DNS in the fewest
exchanges practical
    * recognize that modern clients have to detect and pass any captive
portals and that this may sometimes/often/always-in-practice require Do53
    * support Provisioning Domains specifically and fate-sharing generally
[1]

[1] imagine two RAs from two different ISPs on the same LAN segment; a
client may have to make consistent use of the RA information to use any
encrypted DNS info within that RA

> I know that grovelling around in DHCP/RA can be a nightmare (especially
> for ISPs who might be faced with outdated CPE), but once you accept the
> need to do that, it's not that much harder to ensure all the configuration
> is there.  Besides, you shouldn't need to change the URL often:
> https://www.w3.org/Provider/Style/URI
>
> I think that can easy.  URI templates generally tolerate the addition of
> new field well.  If someone adds {?disable-dnssec} to the template and you
> don't know how to generate that, then you don't need to add it and
> everything works out.  You can build templates that don't work in the
> presence of extensions, but that is something we can manage as we add
> extensions.
>
> --
> Add mailing list
> [email-masked]

---

From: <[email-masked]>
Date: Wed, 11 Mar 2020 09:03:35 +0000

Hi Vittorio, 

Please see inline. 

Cheers,
Med

> De : Add [mailto:[email-masked]] De la part de Vittorio Bertola
> Envoyé : mardi 10 mars 2020 11:00
> À : Stephen Farrell; ADD Mailing list
> Yes, it's an infrequent case, but I would not call it a corner case.
> At least in Europe, there is regulation that requires all ISPs to
> allow users to buy and deploy any CPE they like.

[Med] Agree (assuming the CPE is compliant with the technical specification to access the service published by providers).

Unmanaged CPEs can use the DNS configuration supplied by the network or the user can change that configuration to point to a public resolver. This is similar to what is already discussed in the draft:

   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.

I updated the draft to make this explicit. You may check at: https://github.com/boucadair/draft-btw-add-home-network/blob/master/draft-btw-add-home-03.txt 

   3.  Sample Deployment Scenarios . . . . . . . . . . . . . . . . .   4
     3.1.  Managed CPEs  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Unmanaged CPEs  . . . . . . . . . . . . . . . . . . . . .   7

Do we need to say more? Thanks. 

 Also, it is
> relatively common, for smart users that couldn't get their ISP to do
> without the CPE, to deploy another router in front (LAN-side) of the
> CPE. This happens, for example, because the CPE has the appropriate
> fiber termination but the user's desired home router has not, but has
> other features that the user needs. So indeed these are use cases that
> have to be supported.

[Med] If the internal CPE does not embed a forwarder, that CPE "relays" the DNS information received from the ISP-supplied CPE or use the one set by the user. From a DNS standpoint, this is similar to the scenario above. 

If the internal CPE embeds a forwarder, the procedure we define for bootstrapping with an ISP DoH server + redirection to the forwarder on the CPE does not apply (Section 7 of the I-D). 

Considerations such as those discussed in Section 5.2 will need to be followed by the host/user. Assuming that setup, the internal CPE can use the options defined in the draft (if it supports them) to announce itself as a DoH resolver. Of course, if the user assigns a static address to the internal CPE, it can configure that @ directly on the hosts. Discovery is thus not relevant in such case. 

I'm afraid that we are getting into very specific setups. I suggest to leave this one out for the moment and focus on the scenarios that require less involvement from the user. 

What do you think?

---

From: <[email-masked]>
Date: Wed, 11 Mar 2020 10:11:33 +0000

Hi Martin,

Please see inline.

Cheers,
Med

> Envoyé : mercredi 11 mars 2020 06:05
> I note that you proposed yet another method for resolution in addition
> to the three in that document.  Given the plethora of options we have,
> with no principles driving our decision-making process, it might be
> time for us to collectively determine what those principles might be.

[Med] Indeed, this is what I meant by "we need to think about the overall model".

> I know that grovelling around in DHCP/RA can be a nightmare
> (especially for ISPs who might be faced with outdated CPE), but once
> you accept the need to do that, it's not that much harder to ensure
> all the configuration is there.  Besides, you shouldn't need to change
> the URL often: https://www.w3.org/Provider/Style/URI

[Med] ... but still the design should allow for new services to be defined and others withdrawn. 

Things may be "easy" to manage when both the connectivity and the supplied DNS server are managed by the same ISP, but that is not the case if the ISP relies on a third party service or the user changes the config to point to, e.g., ContainerPI: 

* unfiltered: https://dns.containerpi.com/dns-query
* Filtered, blocks adult content: https://dns.containerpi.com/doh/family-filter/
* Filtered, blocks malicious domains only: https://dns.containerpi.com/doh/secure-filter/

If a new service is added to that list (e.g., https://dns.containerpi.com/doh/secure-family-filter/) or some of them are removed, there is a need to coordinate ** out-of-band ** in order to maintain the configuration supplied to the customers up to date. At least in this example, it is suboptimal to "split the configuration between different domains." (ISP vs. DNS provider).

> I think that can easy.  URI templates generally tolerate the addition
> of new field well.  If someone adds {?disable-dnssec} to the template
> and you don't know how to generate that, then you don't need to add it
> and everything works out.  You can build templates that don't work in
> the presence of extensions, but that is something we can manage as we
> add extensions.

[Med] Practically, we can't guarantee that because we don't know how these extensions will be defined. I would like to avoid requiring an update to the DHCP/RA uri validation code in order to support new extensions.

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 12 Mar 2020 17:29:09 +0100 (CET)

> Il 11/03/2020 10:03 [email-masked] ha scritto:
> 

I think we could mention the use case and make sure that it is not prevented by the architecture we design, assuming that the user is smart (these are not "basic user" situations) and needs to actively configure his/her devices. For the rest, I agree that this is not a priority.

--

---

From: <[email-masked]>
Date: Fri, 13 Mar 2020 09:33:17 +0000

Hi Vittorio,

Sounds good to me. 

We will update the draft with a new section describing that use case. Thank you.

Cheers,
Med

> De : Vittorio Bertola [mailto:[email-masked]]
> Envoyé : jeudi 12 mars 2020 17:29
> Objet : Re: [EXT] RE: [Add] TR: I-D Action: draft-btw-add-home-00.txt
> 
> 
> 
> > [Med] If the internal CPE does not embed a forwarder, that CPE
> "relays" the DNS information received from the ISP-supplied CPE or use
> the one set by the user. From a DNS standpoint, this is similar to the
> scenario above.
> >
> > If the internal CPE embeds a forwarder, the procedure we define for
> bootstrapping with an ISP DoH server + redirection to the forwarder on
> the CPE does not apply (Section 7 of the I-D).
> >
> > Considerations such as those discussed in Section 5.2 will need to
> be followed by the host/user. Assuming that setup, the internal CPE
> can use the options defined in the draft (if it supports them) to
> announce itself as a DoH resolver. Of course, if the user assigns a
> static address to the internal CPE, it can configure that @ directly
> on the hosts. Discovery is thus not relevant in such case.
> >
> > I'm afraid that we are getting into very specific setups. I suggest
> to leave this one out for the moment and focus on the scenarios that
> require less involvement from the user.
> >
> > What do you think?
> 
> I think we could mention the use case and make sure that it is not
> prevented by the architecture we design, assuming that the user is
> smart (these are not "basic user" situations) and needs to actively
> configure his/her devices. For the rest, I agree that this is not a
> priority.
> 
> --
>