Subject: [Add] Fwd: New Version Notification for draft-pauly-add-resolver-discovery-01.txt

From: Tommy Pauly <[email-masked]>
Date: Mon, 13 Jul 2020 14:13:06 -0700

Hello ADD,

We’ve published a revision of draft-pauly-add-resolver-discovery. This revision incorporates various pieces of feedback we’ve received. Specifically, the changes include:

- Aligning with the current version of SCVB/HTTPS records
- Improvements to how to upgrade a local resolver to a DoH resolver 
- Clarification of expiration and TTL of resolver designation
- An appendix describing the choice of using SVCB records for designation, as opposed to other record types or approaches that only provide hints in HTTP responses

We can share details on these changes at the upcoming IETF 108 meeting. We’d like to also start considering how this work can progress as an item for the working group.

Best,
Tommy

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-pauly-add-resolver-discovery-01.txt
> Date: July 13, 2020 at 1:21:32 PM PDT
> To: "Christopher A. Wood" <[email-masked]>, Christopher Wood <[email-masked]>, Tommy Jensen <[email-masked]>, Tommy Pauly <[email-masked]>, Eric Kinnear <[email-masked]>, Patrick McManus <[email-masked]>
> 
> 
> A new version of I-D, draft-pauly-add-resolver-discovery-01.txt
> has been successfully submitted by Tommy Pauly and posted to the
> IETF repository.
> 
> Name:		draft-pauly-add-resolver-discovery
> Revision:	01
> Title:		Adaptive DNS Resolver Discovery
> Document date:	2020-07-13
> Group:		Individual Submission
> Pages:		17
> URL:            https://www.ietf.org/internet-drafts/draft-pauly-add-resolver-discovery-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-pauly-add-resolver-discovery/
> Htmlized:       https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pauly-add-resolver-discovery
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pauly-add-resolver-discovery-01
> 
> Abstract:
>   This document defines a method for dynamically discovering resolvers
>   that support encrypted transports, and introduces the concept of
>   designating a resolver to be used for a subset of client queries
>   based on domain.  This method is intended to work both for locally-
>   hosted resolvers and resolvers accessible over the broader Internet.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 15 Jul 2020 18:23:58 -0400

I don't claim to have understood this proposal in full (for starters, I'm
not familiar with PvD), but it seems like a plausible direction to me.  One
small, but perhaps consequential suggestion:

Instead of placing a "dohuri" SvcParamKey in the HTTPS record (Section
3.1), I think it would be better to put a domain name there (e.g. "resolver=
doh.example.net").  Then the client would do a SVCB query for "_
dns.doh.example.net", retrieving a SVCB record containing the DoH URI (as
in Section 5).  This adds a roundtrip, but I think it maintains better
separation of concerns (e.g. server choice vs. protocol choice).  If lookup
latency is a problem, I think we could find an optional optimization to
collapse this roundtrip (perhaps with a design much like the current draft).

More generally, any use of SVCB requires a mapping document for the
scheme.  I'd be happy to help write a mapping document for dns:// -> _dns,
if we decide to go in that direction.

On Mon, Jul 13, 2020 at 5:16 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hello ADD,
>
> We’ve published a revision of draft-pauly-add-resolver-discovery. This
> revision incorporates various pieces of feedback we’ve received.
> Specifically, the changes include:
>
> - An appendix describing the choice of using SVCB records for designation,
> as opposed to other record types or approaches that only provide hints in
> HTTP responses
>
> We can share details on these changes at the upcoming IETF 108 meeting.
> We’d like to also start considering how this work can progress as an item
> for the working group.
>
> Best,
> Tommy
>
>
> Begin forwarded message:
>
> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-pauly-add-resolver-discovery-01.txt*
> *Date: *July 13, 2020 at 1:21:32 PM PDT
> *To: *"Christopher A. Wood" <[email-masked]>, Christopher Wood <
> [email-masked]>, Tommy Jensen <[email-masked]>, Tommy Pauly <
> [email-masked]>, Eric Kinnear <[email-masked]>, Patrick McManus <
> [email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-pauly-add-resolver-discovery-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-pauly-add-resolver-discovery/
> Htmlized:
> https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-01
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pauly-add-resolver-discovery
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-pauly-add-resolver-discovery-01
>
> Abstract:
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Jul 2020 17:27:39 +0200

On Mon, Jul 13, 2020 at 02:13:06PM -0700,
 Tommy Pauly <tpauly=[email-masked]> wrote 

> We’ve published a revision of draft-pauly-add-resolver-discovery. This revision incorporates various pieces of feedback we’ve received. Specifically, the changes include:

I'm a bit surprised by the use of PvD which, I thought, were meant for
local configuration, not for remote domains but why not.

> Note that clients MUST NOT accept designations for effective top-
>  level domains (eTLDs), such as ".com".

I think I understand why, but it creates a problem for .corp (also
called .brand) TLD. I don't see why the Example Corporation could not
designate a resolver for their ".corp" TLD .example. (A full solution
of this problem would probably require to resurrect the Dbound working
group.)

---

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

I had some more time to read this and try to understand it.  Some more
questions:

Why is DNSSEC needed for use of “dohuri” in SVCB/HTTPS?  An attacker who
can inject this record can also inject false AAAA records for any names of
interest, allowing them to proxy and observe all the user’s traffic (and
disable ECH).  I can believe there's a relevant attack, but it would help
to have an explanation for it.

PvD: The use of "https://example.com/.well-known/pvd" makes sense to me,
but the use of “https://doh.example.net/.well-known/pvd/dns-query" seems
very odd.  Instead, could you do a GET for the DoH URI template with no
“dns” parameter, setting the Accept header to “application/pvd+json”?  That
would avoid the need for coupling across distant paths, and avoid
.well-known’s implication that these are logically properties of the entire
origin.

I'm having trouble understanding which of these mechanisms applies to a
whole subdomain tree, and which apply only to the named domain.  (And even
more trouble understanding why, or why not.)

This draft's PvD mechanism (+PUSH) also seems to overlap considerably with
draft-schinazi-httpbis-doh-preference-hints, which proposes a
"DoH-Preference" response header.  I think we should probably avoid
standardizing both.  The comparison is interesting: I’m not sure PvD is
really the right semantic for this use case, but I do like that it’s
explicitly scoped to the domain.  A response header is syntactically scoped
to a single response, although HTTP headers have been used to convey a
variety of domain-wide information.

One key difference might be how these approaches interact with caching
reverse proxies.  With a (naive) caching reverse proxy in the middle, I’m
not sure how HTTP/2 PUSH would work.  The DoH-Preference header would work,
but it would have to be attached to every response, which seems inefficient.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 22 Jul 2020 17:15:21 -0700

Hi Ben,

Thanks for the comments and thoughts! Responses inline.

> On Jul 22, 2020, at 1:34 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> I had some more time to read this and try to understand it.  Some more questions:
> 
> Why is DNSSEC needed for use of “dohuri” in SVCB/HTTPS?  An attacker who can inject this record can also inject false AAAA records for any names of interest, allowing them to proxy and observe all the user’s traffic (and disable ECH).  I can believe there's a relevant attack, but it would help to have an explanation for it.

We want to verify the designation if we’re going to start steering traffic to a new resolver. This is indeed a higher bar than what an attacker can do for a cleartext record.

Note that DNSSEC is not the only way to prove that the designation is legitimate. It can also happen by checking HTTPS resources that are signed with a name that matches the name or is a parent of the name doing the designation.

For the attack about a user disabling ECH, etc, by blocking packets, that’s an area where a client can protect itself by having a default encrypted resolver, or by using a mechanism like Oblivious DoH.

> 
> PvD: The use of "https://example.com/.well-known/pvd <https://example.com/.well-known/pvd>" makes sense to me, but the use of “https://doh.example.net/.well-known/pvd/dns-query <https://doh.example.net/.well-known/pvd/dns-query>" seems very odd.  Instead, could you do a GET for the DoH URI template with no “dns” parameter, setting the Accept header to “application/pvd+json”?  That would avoid the need for coupling across distant paths, and avoid .well-known’s implication that these are logically properties of the entire origin.

The point of this way of finding the well-known JSON by taking the path into account is to allow specifying information in case multiple DoH servers are running on a given host.

However, it certainly could be OK to do the query like you mention—for our server implementation, it was easier to split out the hosting of a JSON file as opposed to handling DNS messages based on a path, rather than merely an accept content type. It was mainly a practical concern. Happy to bikeshed.

> 
> I'm having trouble understanding which of these mechanisms applies to a whole subdomain tree, and which apply only to the named domain.  (And even more trouble understanding why, or why not.)

I’ve filed an issue to help address this. In general, a designation applies to the whole subdomain tree, but we want to add some additional information in the JSON data to indicate if there is a given subdomain that should be explicitly separated.

https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/121 <https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/121>

Of course, if a more specific subdomain has a different designation, that already would take precedence and cause clients to switch over.

> 
> This draft's PvD mechanism (+PUSH) also seems to overlap considerably with draft-schinazi-httpbis-doh-preference-hints, which proposes a "DoH-Preference" response header.  I think we should probably avoid standardizing both.  The comparison is interesting: I’m not sure PvD is really the right semantic for this use case, but I do like that it’s explicitly scoped to the domain.  A response header is syntactically scoped to a single response, although HTTP headers have been used to convey a variety of domain-wide information.
> 
> One key difference might be how these approaches interact with caching reverse proxies.  With a (naive) caching reverse proxy in the middle, I’m not sure how HTTP/2 PUSH would work.  The DoH-Preference header would work, but it would have to be attached to every response, which seems inefficient.

We will discuss this more in the ADD meeting. I think the preference hints proposal mainly overlaps with the discovery mechanism over DoH, as opposed to the mechanism to discover additional information. From the discovery perspective, we believe that a solution based in DNS and SVCB makes more sense for the DNS operator (with multi-CDN concerns, etc) than putting things in an origin’s response headers.

As for the information, mainly we believe there just needs to be some content (probably JSON) that a client can query on a DoH server to get information about how it can be used. The reason we like PvD here is that it can align with a resolver configuration blob that can be sent directly from a local network. Generally, the reason I see this as fitting PvD semantics is that, since resolver configurations and split-DNS configurations are inherently defining a new set of consistent information about accessing the Internet, it falls under the same purpose as PvD additional information. But this can be a bikeshed too!

Going to your previous comment/suggestion:

I don't claim to have understood this proposal in full (for starters, I'm not familiar with PvD), but it seems like a plausible direction to me.  One small, but perhaps consequential suggestion:

Instead of placing a "dohuri" SvcParamKey in the HTTPS record (Section 3.1), I think it would be better to put a domain name there (e.g. "resolver=doh.example.net").  Then the client would do a SVCB query for "_dns.doh.example.net", retrieving a SVCB record containing the DoH URI (as in Section 5).  This adds a roundtrip, but I think it maintains better separation of concerns (e.g. server choice vs. protocol choice).  If lookup latency is a problem, I think we could find an optional optimization to collapse this roundtrip (perhaps with a design much like the current draft).

More generally, any use of SVCB requires a mapping document for the scheme.  I'd be happy to help write a mapping document for dns:// -> _dns, if we decide to go in that direction.

This is an interesting direction. Certainly, if we can look up the _dns (dns://) SVCB type for a SUDN like resolver.arpa to upgrade a given resolver, being able to look up that type on a domain seems like it should work.

I don’t love the idea of requiring an extra round trip, but I could see that being mitigated if a given client already knows about a resolver, and is just correlating them.

I may suggest a middle-ground: let’s define the “resolver=“ parameter for indicating a designated resolver name in the way you suggest, but also be able to provide hint parameters like what we have here to allow clients to skip the extra round trip if the resolver information in the _dns record is simply a DoH URI or a DoT port.

Best,
Tommy

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

---

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

On Wed, Jul 22, 2020 at 04:34:41PM -0400,
 Ben Schwartz <[email-masked]> wrote 
 a message of 232 lines which said:

> draft-schinazi-httpbis-doh-preference-hints,

Both proposals (draft-schinazi-httpbis-doh-preference-hints and
draft-pauly-add-resolver-discovery) have in common that a Web server
can tell the user agent which DNS resolver to use for subsequent
queries. I'm not convinced it is a good idea. Before discussing the
details of the proposal, did anyone write a pros-and-cons document
about this idea, which is quite new for the Internet?

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 23 Jul 2020 11:02:42 -0400

As a DNS person, I want to use DNS for that discovery mechanism.
I imagine that non-DNS people want to use non-DNS mechanisms for that
discovery.

I would ask how do you see this draft as a better solution than the
add-resinfo draft.

tim

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 23 Jul 2020 11:54:50 -0400

On Wed, Jul 22, 2020 at 8:15 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> On Jul 22, 2020, at 1:34 PM, Ben Schwartz <
> bemasc=[email-masked]> wrote:
>
> We want to verify the designation if we’re going to start steering traffic
> to a new resolver. This is indeed a higher bar than what an attacker can do
> for a cleartext record.
>

Similar steering attacks already exist via A, AAAA, CNAME, and DNAME
records, so this "MUST" seems strange.  Doing this without DNSSEC doesn't
make anything worse than the status quo.

I think it would help if the draft had a clearer confidentiality
criterion.  What guarantee are you trying to provide?  I think this
requirement would be easier to motivate if the guarantee is "Accessing a
webpage that includes subresources from subdomains does not reveal the
subdomain labels to any active attacker when both server and client
implement this specification.".  Even so, this requirement seems
unnecessarily restrictive.

Note that DNSSEC is not the only way to prove that the designation is
> legitimate. It can also happen by checking HTTPS resources that are signed
> with a name that matches the name or is a parent of the name doing the
> designation.
>
> For the attack about a user disabling ECH, etc, by blocking packets,
> that’s an area where a client can protect itself by having a default
> encrypted resolver, or by using a mechanism like Oblivious DoH.
>
>
> The point of this way of finding the well-known JSON by taking the path
> into account is to allow specifying information in case multiple DoH
> servers are running on a given host.
>
> However, it certainly could be OK to do the query like you mention—for our
> server implementation, it was easier to split out the hosting of a JSON
> file as opposed to handling DNS messages based on a path, rather than
> merely an accept content type. It was mainly a practical concern. Happy to
> bikeshed.
>
>
> I’ve filed an issue to help address this. In general, a designation
> applies to the whole subdomain tree, but we want to add some additional
> information in the JSON data to indicate if there is a given subdomain that
> should be explicitly separated.
>
> https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy/issues/121
>
> Of course, if a more specific subdomain has a different designation, that
> already would take precedence and cause clients to switch over.
>
>
> We will discuss this more in the ADD meeting. I think the preference hints
> proposal mainly overlaps with the discovery mechanism over DoH, as opposed
> to the mechanism to discover additional information. From the discovery
> perspective, we believe that a solution based in DNS and SVCB makes more
> sense for the DNS operator (with multi-CDN concerns, etc) than putting
> things in an origin’s response headers.
>
> As for the information, mainly we believe there just needs to be some
> content (probably JSON) that a client can query on a DoH server to get
> information about how it can be used. The reason we like PvD here is that
> it can align with a resolver configuration blob that can be sent directly
> from a local network. Generally, the reason I see this as fitting PvD
> semantics is that, since resolver configurations and split-DNS
> configurations are inherently defining a new set of consistent information
> about accessing the Internet, it falls under the same purpose as PvD
> additional information. But this can be a bikeshed too!
>
>
>>
> This is an interesting direction. Certainly, if we can look up the _dns
> (dns://) SVCB type for a SUDN like resolver.arpa to upgrade a given
> resolver, being able to look up that type on a domain seems like it should
> work.
>
> I don’t love the idea of requiring an extra round trip, but I could see
> that being mitigated if a given client already knows about a resolver, and
> is just correlating them.
>
> I may suggest a middle-ground: let’s define the “resolver=“ parameter for
> indicating a designated resolver name in the way you suggest, but also be
> able to provide hint parameters like what we have here to allow clients to
> skip the extra round trip if the resolver information in the _dns record is
> simply a DoH URI or a DoT port.
>
> Best,
> Tommy
>
>
>
>> --
>> Add mailing list
>> [email-masked]

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 23 Jul 2020 16:00:55 +0000

Hey Tim,

One reason we see our draft as a better approach is that we reuse the record type used for advertising the keys needed for Encrypted ClientHello. This means a client wanting to implement both standards only needs to add one new query type rather than two.

Notice our primary discovery mechanism is a DNS approach (querying for the designation record), as well as our bootstrapping mechanism (querying a resolver for its DoH configuration and confirmed during its handshake). I think we agree on DNS being the best mechanism as it solves many problems that primary discovery through non-DNS mechanism introduces, such as complications with multiple CDN hosting.

However, it also makes sense to allow a DoH client to query a DoH server about its properties once it has discovered the server. The method of using HTTPS to confirm designation is provided as an alternative to DNSSEC, which doesn't enjoy universal deployment even today.

Hey Stephane,

Do you have specific concerns with our approach? Is your question about the concept of Adaptive DNS as a whole (zones designating DNS servers for future queries), or about the specific implementation mechanism (using PvDs, where the designation comes from)?

Thanks,
Tommy Jensen
================================================
The latest in Windows Internet Protocols:
  Native gRPC support: https://aka.ms/grpcblogpost
  DNS over HTTPS: https://aka.ms/dohblogpost

________________________________
From: Add <[email-masked]> on behalf of Tim Wicinski <[email-masked]>
Sent: Thursday, July 23, 2020 8:02 AM
To: Stephane Bortzmeyer <[email-masked]>
Cc: Ben Schwartz <[email-masked]>; David Schinazi <[email-masked]>; ADD Mailing list <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>
Subject: [EXTERNAL] Re: [Add] New Version Notification for draft-pauly-add-resolver-discovery-01.txt

As a DNS person, I want to use DNS for that discovery mechanism.
I imagine that non-DNS people want to use non-DNS mechanisms for that discovery.

I would ask how do you see this draft as a better solution than the add-resinfo draft.

tim

On Thu, Jul 23, 2020 at 10:13 AM Stephane Bortzmeyer <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Jul 22, 2020 at 04:34:41PM -0400,
 Ben Schwartz <[email-masked]<mailto:[email-masked]>> wrote

--
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%7C070284a795a24cf1b9ce08d82f197fb9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637311133847937735&sdata=k8oQTjQvkhq3kqDxq%2FhweUlvJr7yvQ%2BhKAEio3nTxT4%3D&reserved=0>

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 23 Jul 2020 18:13:16 +0200 (CEST)

> Il 23/07/2020 16:13 Stephane Bortzmeyer <[email-masked]> ha scritto:
> 

Also, I don't think I heard any explanation of how this (having each destination domain provide its own resolver) is better than just getting rid of (intermediate) resolvers and letting each client connect directly to the authoritatives for the destination domain - something which would already be possible today without the need for new protocols. What's the advantage of locating a resolver just in front of the authoritative?

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 23 Jul 2020 17:31:39 +0100

Vittorio Bertola <[email-masked]> wrote:
>
> Also, I don't think I heard any explanation of how this (having each
> destination domain provide its own resolver) is better than just getting
> rid of (intermediate) resolvers and letting each client connect directly
> to the authoritatives for the destination domain - something which would
> already be possible today without the need for new protocols. What's the
> advantage of locating a resolver just in front of the authoritative?

A stub resolver isn't able to chase CNAMEs or delegations, so if the
destination site has a setup that is even slightly non-trivial, stub
resolvers will need to use a recursive server to walk the namespace for
them.

DNS with RD=1 and RD=0 are different protocols in a similar way to message
submission and SMTP-to-MX - they involve different protocol semantics
(especially in terms of what is allowed or forbidden) even though the
syntax is similar, and the trust boundaries and relationships are quite
different.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Isle of Man: Northwest 3 or 4 backing south 4 or 5 later. Slight, occasionally
moderate later. Fair, rain later. Good, occasionally moderate or poor later.

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 23 Jul 2020 09:54:01 -0700

> On Jul 23, 2020, at 7:13 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Hi Stephane,

To be clear, draft-pauly-add-resolver-discovery does not have any mechanism in which a client learns from arbitrary Web server about which DNS resolver to use. All of the designation for resolvers occurs either from DNS records, or from information fetched directly from a DNS server (as a request to the DoH server for a JSON configuration file). We believe it is important to root this in DNS.

Thanks,
Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 23 Jul 2020 09:58:22 -0700

I agree that the discovery should all be based in DNS. The mechanism described in draft-pauly-add-resolver-discovery uses DNS messages for discovery, and can use additional information served up by a DoH server. It does not get any discovery information from arbitrary web servers, and I think doing so would be a problem for deployment models.

Regarding the way to fetch JSON information—be that in a GET request to a DoH server or with a new RRType—I think that is something that can equally go either way, and I’d be happy to see this bike-shedded. To that end, I think these approaches can be reconciled and combined. What is more important for us is the content of the information and how it is used.

Thanks,
Tommy

> On Jul 23, 2020, at 8:02 AM, Tim Wicinski <[email-masked]> wrote:
> 
> On Thu, Jul 23, 2020 at 10:13 AM Stephane Bortzmeyer <[email-masked] <mailto:[email-masked]>> wrote:
>  Ben Schwartz <[email-masked] <mailto:[email-masked]>> wrote

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 23 Jul 2020 12:59:19 -0400

Thanks Tommy.

Stephane also pointed out I was confusing my drafts in my replies.  So you
should just carry on.

tim

On Thu, Jul 23, 2020 at 12:58 PM Tommy Pauly <[email-masked]> wrote:

> I agree that the discovery should all be based in DNS. The mechanism
> described in draft-pauly-add-resolver-discovery uses DNS messages for
> discovery, and can use additional information served up by a DoH server. It
> does not get any discovery information from arbitrary web servers, and I
> think doing so would be a problem for deployment models.
>
> Regarding the way to fetch JSON information—be that in a GET request to a
> DoH server or with a new RRType—I think that is something that can equally
> go either way, and I’d be happy to see this bike-shedded. To that end, I
> think these approaches can be reconciled and combined. What is more
> important for us is the content of the information and how it is used.
>
> Thanks,
> Tommy
>

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 24 Jul 2020 10:42:05 +0200 (CEST)

> Il 23/07/2020 18:31 Tony Finch <[email-masked]> ha scritto:
> 

Of course in this scenario you would then have a full resolver in the client, which is something that browsers etc could already have today. It would even make DNSSEC more useful, by not relying on a third party (the resolver) for validation. 

You need to discuss whether the additional complexity in the client would be a problem, and you would have to compare it with the additional complexity of each destination domain having to also provide a resolver; and you need to discuss the privacy implications, as until now having the ISP's resolver aggregate queries by all its users and cache most results was also considered a form of privacy protection that would disappear both if clients had a full resolver and if clients had a stub resolver that directly contacts each destination domain (with Tommy's counter-argument that these domains would get contacted anyway at the following step, i.e. the application level connection). 

These are examples of the discussions that we could be having in the "pros-and-cons" analysis suggested by Stéphane.

---

From: Tony Finch <[email-masked]>
Date: Fri, 24 Jul 2020 17:53:02 +0100

Vittorio Bertola <[email-masked]> wrote:
>
> Of course in this scenario you would then have a full resolver in the
> client, which is something that browsers etc could already have today.

Except that stub resolvers have to cope with networks that don't allow
end-user devices to talk to arbitrary authoritative DNS servers.

> It would even make DNSSEC more useful, by not relying on a third party
> (the resolver) for validation.

DNSSEC validation is perfectly possible whether or not you are using a
recursive server. There are several validating stub resolvers. There's no
need to trust your recursive server's validation. Stubs that don't do
DNSSEC validation are for backwards compatibility, not part of the DNSSEC
architecture.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
public services of the highest quality

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 24 Jul 2020 10:00:38 -0700

> On Jul 24, 2020, at 9:53 AM, Tony Finch <[email-masked]> wrote:
> 

Right. The designated encrypted resolver for a given domain or zone may be equivalent to its authoritative server, but (a) it may not always be the same, (b) the authoritative may not always be accessible, and (c) even if the clients stubs can chase CNAMEs and delegations, its far more efficient to not require that.

> DNSSEC validation are for backwards compatibility, not part of the DNSSEC

DNSSEC validation is indeed a case that the client reasonably would want to do on its own. I could see a world in which if we trust a designated server for a zone, we would trust its hints about DNSSEC (or not really need to validate DNSSEC, since we have a more trusted channel), but validating records that come from an arbitrary resolver provisioned by the network (especially an unencrypted and unauthenticated one) should usually involve the client stub doing the full validation.

Best,
Tommy

---

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

On Thu, Jul 23, 2020 at 04:00:55PM +0000,
 Tommy Jensen <[email-masked]> wrote 
 a message of 276 lines which said:

> Do you have specific concerns with our approach? Is your question
> about the concept of Adaptive DNS as a whole (zones designating DNS
> servers for future queries), or

I did not even know the term of "Adaptive DNS". It is not in RFC
8499. Is it in common use?

So, yes, I have concerns with the idea of having a Web site directing
the future DNS queries, I'm afraid it will make debugging harder (you
cannot know which resolver was used, there can be many in a typical
Web session).

For the related idea of a DNS zone directing to specific resolvers,
I'm confused: isn't it simply what DNS delegation is about?

---

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

On Fri, Jul 24, 2020 at 05:53:02PM +0100,
 Tony Finch <[email-masked]> wrote 
 a message of 21 lines which said:

> Except that stub resolvers have to cope with networks that don't
> allow end-user devices to talk to arbitrary authoritative DNS
> servers.

These violations of network neutrality seem a reason to use DoH (or
DoT) with authoritative name servers.

---

From: Tommy Jensen <[email-masked]>
Date: Mon, 27 Jul 2020 16:51:07 +0000

Adaptive DNS was originally the draft name until the content was split into multiple documents. That's my bad. What I meant to refer to was the concept altogether of DNS zones designating their preferred DoH resolvers.

Keep in mind as Tommy Pauly said to Tim on a different fork that the primary discovery mechanism for DoH resolver designation is through the DNS itself (via SVCB records queried alongside the typical A/AAAA). The HTTPS channels are used for confirming that SVCB claim or to ask the DoH server itself about what zones it has been delegated.

Thanks,
Tommy Jensen
================================================
The latest in Windows Internet Protocols:
  Native gRPC support: https://aka.ms/grpcblogpost
  DNS over HTTPS: https://aka.ms/dohblogpost
________________________________
From: Stephane Bortzmeyer <[email-masked]>
Sent: Monday, July 27, 2020 7:23 AM
To: Tommy Jensen <[email-masked]>
Cc: Tim Wicinski <[email-masked]>; Stephane Bortzmeyer <[email-masked]>; Ben Schwartz <[email-masked]>; David Schinazi <[email-masked]>; ADD Mailing list <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>
Subject: [EXTERNAL] Re: New Version Notification for draft-pauly-add-resolver-discovery-01.txt

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 27 Jul 2020 14:38:47 -0400

> > servers for future queries), or
...

> I'm confused: isn't it simply what DNS delegation is about?

To me, this is the most interesting question about this draft.  The
proposal is so close to DPRIVE's ADoT charter that it feels like there
ought to be a unified solution.

Earlier, Tony Finch wrote:

> resolvers will need to use a recursive server to walk the namespace for

This makes me wonder, could we solve this with a flag on delegations that
means "I promise I can answer any question below this point, no need for
recursion", or perhaps "there are no zone cuts below this point"?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Jul 2020 20:47:24 +0000

> DoT) with authoritative name servers.

in the USA at this time, network neutrality is nobody's obligation.

on privately operated edge networks having only employees or family but no 
customers, network neutrality will never be an obligation. on those networks, 
DoH will be seen as, and treated as, an attack.

i don't think network neutrality is a useful rubric for ADD's proposals.

-- 
Paul

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jul 2020 22:15:38 +0100

Paul,

> DoH will be seen as, and treated as, an attack.

I run a home network and consider DoH a fine countermeasure
against the potential I have to snoop on my family and all
of our visitors.

I don't question your right to hold your view of DoH. I do
maintain mine is as legitimate.

S.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Jul 2020 21:32:10 +0000

On Monday, 27 July 2020 21:15:38 UTC Stephen Farrell wrote:
> > customers, network neutrality will never be an obligation. on those
> > networks, DoH will be seen as, and treated as, an attack.
> 

your network, your rules. even if i disagreed with your chosen policy i would 
fight for your right to make and enforce that policy. so, your local policy 
will always be legitimate in my eyes, no matter what policy that may be.

service provider networks who usurp the prerogatives of private network 
operators to surveil or filter without transparency or permission are the root 
cause of DoH and DoT. something's got to be done about those usurpers, and 
encryption of DNS (with DoH or DoT or otherwise) is a move in that direction.

however, on privately operated edge networks (corporate, government, military, 
family) we ought to expect DoH to be treated as an attack, and never welcomed, 
and often blocked. i think we should treat that policy as legitimate, and not 
make it more expensive to implement than is otherwise necessary.

that's the broad spectrum of our problem statement as i see it.

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jul 2020 17:50:29 -0400

> make it more expensive to implement than is otherwise necessary.

I think it’s been generally agreed that there are networks on which DoH should not be allowed. I’m puzzled that you think this is controversial. What about it is controversial? The existence of such a policy, or the mechanism for enforcing it?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Jul 2020 22:00:43 +0000

On Monday, 27 July 2020 21:50:29 UTC Ted Lemon wrote:
> I think it’s been generally agreed that there are networks on which DoH
> should not be allowed. I’m puzzled that you think this is controversial.
> What about it is controversial? The existence of such a policy, or the
> mechanism for enforcing it?

i'd like ADD to recommend a protocol which can be identified by a private 
firewall, so that it can be reliably blocked without guesswork. this may mean 
DoT rather than DoH, because DoH is _designed_ to prevent on-path interference 
in DNS operations.

i'd like ADD to recommend a protocol by which policy violations can receive 
secure authentic unambiguous refusal signals, rather than silence. this may 
require explicit negotiation between a node and its gateway.

i'd like ADD to be useful as a way to bootstrap secure and authenticated 
sensitive configuration information, since DHCP has been declared unsecure. 
this may mean introducing some local namespace (servers and DNSSEC keys).

all of this flows through our choice of DNS resolver discovery method.

all of this is considered controversial by many here.

-- 
Paul

---

From: Rob Sayre <[email-masked]>
Date: Mon, 27 Jul 2020 15:04:55 -0700

On Mon, Jul 27, 2020 at 3:01 PM Paul Vixie <[email-masked]> wrote:

>
> i'd like ADD to recommend a protocol by which policy violations...
>

Off-topic.

thanks,
Rob

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jul 2020 18:09:21 -0400

> all of this is considered controversial by many here.

Yes, we’ve been around and around on this. It’s not that it’s controversial. It’s that ADD telling people what to do has to be useful to the people who are being told what to do, or they won’t do it. If ADD tells people to do something that doesn’t serve the interests of their customers, they aren’t going to do it.

So what we’ve been having here isn’t a controversy—it’s an exchange of slogans. There’s no actual controversy. You think network operators have a right to act in the interests of their customers, which in your case is the organization that owns the network, not the end user. I don’t think anybody disagrees with you about this.

You think that the way to solve this problem is for ADD to say “don’t use DoH.” But many participants in ADD are here to figure out how to do DoH, and aren’t interested in your opinion that they should not do it. I suppose it’s theoretically possible that you could come up with some argument that would convince them, but I don’t know what it would be, and clearly you don’t either, because you haven’t made any such argument. You just keep repeating these slogans. That’s not going to get the job done.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jul 2020 23:11:21 +0100

Hiya,

> will always be legitimate in my eyes, no matter what policy that may be.

Cool.

> encryption of DNS (with DoH or DoT or otherwise) is a move in that direction.

I wouldn't describe things in terms of a tussle between
entities that want to surveil myself, though I agree that
such entities do certainly exist and are numerous. I'd
rather also include a description that's based around what
I see as people's right to privacy.

> make it more expensive to implement than is otherwise necessary.

That depends - it's not clear to me we can square the
circle between e.g. my policy and ones representing the
kind of tussle between mutually-antagonistic snooping
entities you describe above.

Cheers,
S.

PS: I'm not ignoring the fact that the (e.g. HTTP) server
endpoints aren't also snooping - they clearly are, and are
in many ways worse than the snoopers Paul mentions at the
top.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Jul 2020 22:15:14 +0000

> > i'd like ADD to recommend a protocol by which policy violations...

attempts at quick dismissal are unhelpful. if ADD WG ultimately decides not to 
address predicted, defined, known, deliberate failure modes, by adding 
explicit signaling for those "abuse cases", it'll be after we discuss it.

-- 
Paul

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 27 Jul 2020 22:18:29 +0000

From: Rob Sayre

On Mon, Jul 27, 2020 at 3:01 PM Paul Vixie <[email-masked]<mailto:[email-masked]>> wrote:

Off-topic.

<BHS> From the ADD charter:
- 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.

Since this is in the charter, discussion of such mechanisms appear to me to be firmly “on topic”. But I defer to the chairs to decide if considering protocol mechanisms to communicate information about the specific network environment are off topic. Per the charter, even if the protocol mechanisms are new, they would have to be in an informational document. But that’s never stopped anyone from implementing something if it’s useful.</BHS>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 27 Jul 2020 22:20:43 +0000

<BHS> No, I think it’s about ADD saying “here is how the network can tell hosts and apps that the network considers anything it catches doing DoH to be malware”.</BHS>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jul 2020 18:25:32 -0400

> <BHS> No, I think it’s about ADD saying “here is how the network can tell hosts and apps that the network considers anything it catches doing DoH to be malware”.</BHS>

Okay, but on the one hand if you mean that the network might intercept a connection to a known DoH server and send a TLS alert saying “don’t,” I don’t think that’s at all controversial. I’d support doing that. Maybe ekr would have some nit, but I think the idea that that might be useful isn’t terribly controversial.

If on the other hand you mean that we should write a document saying “the network should tell you with DHCP not to do DoH,” then it’s going to be very hard to get consensus on that, because my code wouldn’t even go look to see whether the network had said that, much less honor its request. If you think my code ought to honor the request, then I suppose have at it, but that’s what I mean when I say that we’re just hearing slogans. I haven’t heard any convincing argument that I should write code that does that. The slogans aren’t going to get it done.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 27 Jul 2020 15:50:11 -0700

On Mon, Jul 27, 2020 at 3:26 PM Ted Lemon <[email-masked]> wrote:

>
> If on the other hand you mean that we should write a document saying “the
> network should tell you with DHCP not to do DoH,” then it’s going to be
> very hard to get consensus on that...
>

I agree. After all, malware will ignore this signal.

thanks,
Rob

---

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

> I agree. After all, malware will ignore this signal.

manageability is one aspect of security, going to its deployment costs rather 
than to its nondeployment risks. reliable signaling about what's denied by 
policy reduces the complexity of the diagnostic flow chart when something's 
not working, both for the user, the help desk, and the vendor.

in counterpoint, arguments in favour of the deliberate entropy of DoH have 
sometimes taken the form "if we make this easy to detect, then it will be 
widely blocked", which presumes that the alternative cost of blocking DoH can 
be artificially raised above the accepted risks of not blocking it.

engineering and security both rely heavily on economics to determine the 
quality of a design.

i don't think ADD-WG will as a whole deliberately choose to raise the security 
costs for operators of private edge networks, though some here may wish it so, 
either as a necessary tradeoff or as forced reeducation as to internet 
virality.

(also, i didn't say what ted's quote above implies i might have meant.)

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jul 2020 19:51:04 -0400

> not working, both for the user, the help desk, and the vendor.

This sounds like you are just asking for the equivalent of an HTTP 451 response. That would allow the software that is relying on a DoH server to know that it has been blocked and why.

> be artificially raised above the accepted risks of not blocking it.

Yes, that is the argument, and it makes sense. If we make DoH easy to detect, then there is no point in having DoH: it serves no purpose.

> engineering and security both rely heavily on economics to determine the 

Another way to put this is that the way you make something secure is by making it more expensive to attack than the benefit you’d get from attacking it, right?

> either as a necessary tradeoff or as forced reeducation as to internet 

I think that the emergence of TLS increased some security costs substantially, and has continued to do so as TLS security has improved in newer versions. There was a huge controversy about this for TLS 1.3.  Once you have TLS, certain security guarantees can only be obtained by MiTMing all TLS connections. But of course, making it easy to MiTM TLS makes TLS not serve the purpose for which it was intended. That purpose is to protect the information that is being transmitted over TLS connections. E.g., credit card data, passwords, porn, whatever.

There is a clear cost to society of providing this protection. There is a clear cost to society of not providing this protection. If you think about it, the ongoing COVID lockdown would be a lot harder if we didn’t have transport layer security we could depend on. So much of what we’ve been doing to cope relies on secure communications.

So in a world where we care about transport layer security, there are some things you can legitimately ask for, and some things that, if you ask for them, will just get you a blank, puzzled stare.  If you ask to be able to MiTM the transport layer security, you’re going to get told that you’d better own one of the endpoints or no.  “Control the endpoints” can mean that you control the network services, because you manage them, or it can mean that you control the devices, and have installed your own root signing cert on them.

A corollary to that is that if you don’t own one of the endpoints, and you want to attack the user, the only (reasonable cost) attack you can do is a DoS attack. The effect of this will be that the devices on either endpoint will be unable to communicate. This is a good outcome: it would be a bad outcome if they tried to communicate through the MiTM.

Is there anything I’m saying here that you disagree with? I’m really not understanding where the disconnect is.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2020 17:11:26 -0700

On Mon, Jul 27, 2020 at 4:51 PM Ted Lemon <[email-masked]> wrote:

> Yes, that is the argument, and it makes sense. If we make DoH easy to
> detect, then there is no point in having DoH: it serves no purpose.
>

>From my perspective, this is not correct.

DoH has a number of technical advantages over DoT (for instance the ability
to use Alt-Svc to upgrade to DoH3). Of course, one might or might not value
these benefits against having two protocols, but that's not quite the same
thing.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Jul 2020 20:27:59 -0400

On Jul 27, 2020, at 8:11 PM, Eric Rescorla <[email-masked]> wrote:
> DoH has a number of technical advantages over DoT (for instance the ability to use Alt-Svc to upgrade to DoH3). Of course, one might or might not value these benefits against having two protocols, but that's not quite the same thing.

Okay, fair point, DoH can just be a better protocol as well as being a way to get privacy. A better way to have put that would be that making DoH easy to detect blocks one of the main benefits of DoH: that it gives the user privacy from on-path snoopers in a way that can’t be easily blocked.

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 28 Jul 2020 00:44:08 +0000

(+1 to ekr's point)

I agree with Ted: we shouldn't go weakening strong end-to-end encrypted protocols on purpose. From an endpoint's perspective, there is no authoritative way to distinguish between network administration ("good") and network attacks ("bad") without some prior knowledge and trust of the network, such as preinstalled certificates. Arguably, these networks which want to tightly control network behavior ought to tightly control network joining capabilities to prevent this perceived misbehavior. Otherwise, any side door we build for MitM to more readily block/downgrade communication between intended endpoints will be a side door attackers can use as well.

If we want to allow networks to give new and arbitrary endpoints a trusted (defined as "client can securely distinguish from an arbitrary attacker") signal that a given communication mechanism is forbidden, we (not this WG) should work on that on a larger scale. After all, such a mechanism could be used to signal network opposition to VPN tunnels, Tor connections, or anything else a network find offensive. If it works for HTTPS, DoH should inherit the benefits gracefully.

What I'm saying is: we should leave this discussion off this list because it isn't specific to encrypted DNS as networks opposing encrypted communication to an endpoint has existed before DoH or DoT. Per the charter quote below, we can inform about mechanisms available to detect these network intentions, but I would say creation of new mechanisms is beyond the scope of the charter. Chairs can correct me if I interpreted that incorrectly.

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

Thanks,
Tommy Jensen
================================================
The latest in Windows Internet Protocols:
  Native gRPC support: https://aka.ms/grpcblogpost
  DNS over HTTPS: https://aka.ms/dohblogpost
________________________________
From: Add <[email-masked]> on behalf of Ted Lemon <[email-masked]>
Sent: Monday, July 27, 2020 5:27 PM
To: Eric Rescorla <[email-masked]>
Cc: [email-masked] <[email-masked]>; Paul Vixie <[email-masked]>; STARK, BARBARA H <[email-masked]>; Rob Sayre <[email-masked]>
Subject: [EXTERNAL] Re: [Add] New Version Notification for draft-pauly-add-resolver-discovery-01.txt

On Jul 27, 2020, at 8:11 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

---

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

On Tuesday, 28 July 2020 00:44:08 UTC Tommy Jensen wrote:
> (+1 to ekr's point)
> 
> I agree with Ted: we shouldn't go weakening strong end-to-end encrypted
> protocols on purpose. From an endpoint's perspective, there is no
> authoritative way to distinguish between network administration ("good")
> and network attacks ("bad") without some prior knowledge and trust of the
> network, such as preinstalled certificates. ...

since i was nearby when ted's and ekr's comments were made, let me state for 
the record that ted's opposition was to something i hadn't proposed, and may 
represent a misrestatement on his part, or perhaps a misunderstanding. as 
such, ekr's response was nonsequitur through no fault of his own, and i can 
neither confirm nor deny my position with respect to it. i don't want to get 
in the way of the great discussion you folks want to have, other than to 
remind you all, it's actually off-topic from the remarks it quotes from me.

> ... Arguably, these networks which
> want to tightly control network behavior ought to tightly control network
> joining capabilities to prevent this perceived misbehavior. ...

when DoH is going to be denied, i'd like the node to get an accurate signal 
about that, rather than silent failure. that's not a political goal, but a 
customer service level goal. since DoH is in fact going to be widely denied, 
and sometimes that will be by the owner/operator of the network and the node, 
this adds a transparency and manageability burden to ADD. if you imagine that  
one form of misbehaviour is sudden unexpected unauthorized DoH use as a side 
effect of a browser upgrade, then you might reconsider the word "tightly".

> ... Otherwise, any
> side door we build for MitM to more readily block/downgrade communication
> between intended endpoints will be a side door attackers can use as well.

consent will sometimes be withheld. bypass will be seen as an attack. defense 
will occur. what do you want to see happen next? i'd like reliable signaling 
with complete transparency: "you can't do what you're trying on this network."

in my estimation, none of the agencies edward snowden warned us about in 2013 
are going to be transparent about surveillance or filtering, so your fear of 
them using reliable denial signaling as part of negotiation seems misplaced.

but to repeat, what do you want to see happen during administrative denials? 
right now it's unexplained silence and failure. i think that's bad customer 
service, and i want us to strive for better. if an on-path actor is willing to 
tell you what you can't do and why not, and identify themselves, we should be 
willing to do the work involved to make that telling possible.

-- 
Paul

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2020 06:39:50 -0400

> On Jul 28, 2020, at 03:34, Paul Vixie <[email-masked]> wrote:

That’s not the concern. The concern is that if DoH traffic is labeled specifically so that the network can identify it, it will be blocked, with or without notification. Signaling that a particular TLS connection is DoH does you no good and does the user harm.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 28 Jul 2020 13:33:21 +0200 (CEST)

> Il 28/07/2020 12:39 Ted Lemon <[email-masked]> ha scritto:
> 
>  
> That’s not the concern. The concern is that if DoH traffic is labeled specifically so that the network can identify it, it will be blocked,

Why?

There will be networks that want to block DoH, and there will be others that don't, and there will be others that will say that you can have DoH but only if you use the local resolver, or if you use a resolver from a specific list, or will suggest you a local resolver but then accept a different choice.

Then, there will be clients (both on behalf of the user, i.e. anonymizing browsers, and against the user, i.e. malware) that will want to ignore that policy if they dislike it, and do something else - and there will be networks that will then react by doing all sorts of bad things to traffic from those clients.

We cannot do much in the case when clients (users) and networks (network providers) disagree, and that case will always exist, but there is a number of use cases (hopefully most of them) in which users and network providers will cooperate to find a mutually acceptable configuration. What we should develop is a way for the client to discover the local DoH resolver's location and the network policy attached to it, so that the above agreement becomes possible in those cases. What the client does with that information, and whether the client chooses to abide by or defy the local policy, will then be a choice for the developers of each client (and for their lawyers and policy officers, I suspect, but that's another discussion).

On the other hand, refusing to standardize such a mechanism would be quite a strong policy stance, as it would assume that all networks will always be adversarial and badly intentioned so there is no use in even listening to what they would like to say. I don't think that the IETF should go down that path.

---

From: tirumal reddy <[email-masked]>
Date: Tue, 28 Jul 2020 12:23:11 +0000

On Tue, 28 Jul 2020 at 00:44, Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> network, such as preinstalled certificates.
>

Secure discovery is possible in several scenarios and the client can
identify/authenticate the local DoH/DoT server, for example see
https://tools.ietf.org/html/draft-reddy-add-iot-byod-bootstrap-01
<https://tools.ietf.org/html/draft-reddy-add-iot-byod-bootstrap-00> and
https://tools.ietf.org/html/draft-btw-add-ipsecme-ike-00. In deployments
where secure discovery is not possible, client validation techniques like
pre-configured TRR or cryptographic assertion of the DNS server identity
would ensure the client does not connect to an attacker's DoH/DoT server.

> Arguably, these networks which want to tightly control network behavior
> ought to tightly control network joining capabilities to prevent this
> perceived misbehavior. Otherwise, any side door we build for MitM to more
> readily block/downgrade communication between intended endpoints will be a
> side door attackers can use as well.
>

IT-managed endpoint devices can be tightly controlled by management
software but not BYOD (without MDM/configuration profile). In deployments
like home networks, the network security service co-located in the home
router has no way to manage or tightly control endpoint and IoT devices.

-Tiru

>
> If we want to allow networks to give new and arbitrary endpoints a trusted
> (defined as "client can securely distinguish from an arbitrary attacker")
> signal that a given communication mechanism is forbidden, we (not this WG)
> should work on that on a larger scale. After all, such a mechanism could be
> used to signal network opposition to VPN tunnels, Tor connections, or
> anything else a network find offensive. If it works for HTTPS, DoH should
> inherit the benefits gracefully.
>
> What I'm saying is: we should leave this discussion off this list because
> it isn't specific to encrypted DNS as networks opposing encrypted
> communication to an endpoint has existed before DoH or DoT. Per the charter
> quote below, we can inform about mechanisms available to detect these
> network intentions, but I would say creation of new mechanisms is beyond
> the scope of the charter. Chairs can correct me if I interpreted that
> incorrectly.
>
> >> 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.
>
> Thanks,
> Tommy Jensen
> ------------------------------
> *From:* Add <[email-masked]> on behalf of Ted Lemon <
> [email-masked]>
> *Sent:* Monday, July 27, 2020 5:27 PM
> *To:* Eric Rescorla <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>; Paul Vixie <[email-masked]>; STARK,
> BARBARA H <[email-masked]>; Rob Sayre <sayrer@gmail..com>
> *Subject:* [EXTERNAL] Re: [Add] New Version Notification for
> draft-pauly-add-resolver-discovery-01.txt
>
> On Jul 27, 2020, at 8:11 PM, Eric Rescorla <[email-masked] <ekr@rtfm..com>>
> wrote:
>
> DoH has a number of technical advantages over DoT (for instance the
> ability to use Alt-Svc to upgrade to DoH3). Of course, one might or might
> not value these benefits against having two protocols, but that's not quite
> the same thing.
>
>
> Okay, fair point, DoH can just be a better protocol as well as being a way
> to get privacy. A better way to have put that would be that making DoH easy
> to detect blocks one of the main benefits of DoH: that it gives the user
> privacy from on-path snoopers in a way that can’t be easily blocked.
>
>
> --
> Add mailing list
> [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Jul 2020 15:49:48 +0200

On Mon, Jul 27, 2020 at 10:00:43PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 23 lines which said:

> i'd like ADD to recommend a protocol by which policy violations can
> receive secure authentic unambiguous refusal signals, rather than
> silence. this may require explicit negotiation between a node and
> its gateway.

We already have it, it seems, with draft-ietf-dnsop-extended-error,
which is approved and in the RFC Editor queue (state RFC-EDITOR).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Jul 2020 15:51:54 +0200

On Mon, Jul 27, 2020 at 07:51:04PM -0400,
 Ted Lemon <[email-masked]> wrote 
 a message of 234 lines which said:

> This sounds like you are just asking for the equivalent of an HTTP
> 451 response.

And it exists, in draft-ietf-dnsop-extended-error.

4.16.  Extended DNS Error Code 15 - Blocked

   The server is unable to respond to the request because the domain is
   blacklisted due to an internal security policy imposed by the
   operator of the server resolving or forwarding the query.

4.17.  Extended DNS Error Code 16 - Censored

   The server is unable to respond to the request because the domain is
   blacklisted due to an external requirement imposed by an entity other
   than the operator of the server resolving or forwarding the query.
   Note that how the imposed policy is applied is irrelevant (in-band
   DNS filtering, court order, etc).

4.18.  Extended DNS Error Code 17 - Filtered

   The server is unable to respond to the request because the domain is
   blacklisted as requested by the client.  Functionally, this amounts
   to "you requested that we filter domains like this one."

4.19.  Extended DNS Error Code 18 - Prohibited

   An authoritative server or recursive resolver that receives a query
   from an "unauthorized" client can annotate its REFUSED message with
   this code.  Examples of "unauthorized" clients are recursive queries
   from IP addresses outside the network, blacklisted IP addresses,
   local policy, etc.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 28 Jul 2020 16:02:55 +0200 (CEST)

> Il 28/07/2020 15:51 Stephane Bortzmeyer <[email-masked]> ha scritto:
>  

What is still missing is a standard way for the resolver to communicate a URL to the client in the response, so that the client (if it wants) can use it to retrieve and display a human-readable error message.

---

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

> which is approved and in the RFC Editor queue (state RFC-EDITOR).

This works if the DoH server that sends the error response is the intended server. However, it doesn’t work when the network is blocking the connection to an off-network DoH server. For that I think you need a TLS alert.

> What is still missing is a standard way for the resolver to communicate a URL to the client in the response, so that the client (if it wants) can use it to retrieve and display a human-readable err…

That would be an attack surface—now I can intercept your connection and send you to a malware URL (or snooping URL, or whatever). And again would only work if the DoH server sending the response is the one with which the device connecting to it intended to communicate.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 28 Jul 2020 16:31:07 +0200 (CEST)

>     Il 28/07/2020 16:13 Ted Lemon <[email-masked]> ha scritto:
>      
>      
>     On Jul 28, 2020, at 10:02 AM, Vittorio Bertola <[email-masked] mailto:[email-masked] > wrote:
> 
Of course that requires some security considerations and validation before use, but if you assume that you cannot trust the (https) URL indicated in the EDNS response, then you cannot trust the response itself and its indication that the domain was blocked for whatever reason, and possibly you cannot trust any DNS response whatsoever. In any case, it might be that clients will only use that information if it is received over an authenticated channel (e.g. via DoH).

--

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: Tue, 28 Jul 2020 14:41:57 +0000

>    from IP addresses outside the network, blacklisted IP addresses,

https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04 conveys
the resolver information, it includes the reasons for performs filtering:

   malwareblocking:  The DNS server offers malware blocking service.
         If access to domains is blocked on threat data, the parameter
         value is set to 'true'.  Note that some of the commonly known
         types of malware are viruses, worms, trojans, bots, ransomware,
         backdoors, spyware, and adware.

      phishingblocking:  The DNS server offers phishing blocking
         service.  If access to phishing domains is blocked, the
         parameter value is set to 'true'.

      policyblocking:  If access to domains is blocked due to an
         internal policy imposed by the operator of the DNS server, the
         parameter value is set to 'true'.  Note that the extended error
         code "Blocking" defined in Section 4.16 of
         [I-D.ietf-dnsop-extended-error
<https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04#ref-I-D.ietf-dnsop-extended-error>]
identifies access to domains is
         blocked due to an policy by the operator of the DNS server.

      censoredblocking:  If access to domains is blocked due to an
         external requirement imposed by an external entity, the
         parameter value is set to 'true'.  Note that the extended error
         code "Censored" defined in Section 4.17 of
         [I-D.ietf-dnsop-extended-error
<https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04#ref-I-D.ietf-dnsop-extended-error>]
identifies access to domains is
         blocked based on a requirement from an external entity.
         Similar to the definition of "Censored" blocking in
         [I-D.ietf-dnsop-extended-error
<https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04#ref-I-D.ietf-dnsop-extended-error>],
this version of the
         specification does not distinguish blocking from regulatory
         bodies (e.g., Law Enforcement Agency) vs.  arbitrary blocking.

Cheers,
-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Tue, 28 Jul 2020 14:43:38 +0000

On Tue, 28 Jul 2020 at 14:03, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> What is still missing is a standard way for the resolver to communicate a
> URL to the client in the response, so that the client (if it wants) can use
> it to retrieve and display a human-readable error message.
>

Yup, https://tools.ietf.org/html/draft-reddy-dnsop-error-page-02 explains a
method to return an URL that explains the reason the DNS query was
filtered.

---

From: tirumal reddy <[email-masked]>
Date: Tue, 28 Jul 2020 14:49:35 +0000

On Tue, 28 Jul 2020 at 14:31, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> On Jul 28, 2020, at 10:02 AM, Vittorio Bertola <
> vittorio.bertola@open-xchange..com <[email-masked]>>
> wrote:
>
>
> That would be an attack surface—now I can intercept your connection and
> send you to a malware URL (or snooping URL, or whatever). And again would
> only work if the DoH server sending the response is the one with which the
> device connecting to it intended to communicate.
>
> Of course that requires some security considerations and validation before
> use, but if you assume that you cannot trust the (https) URL indicated in
> the EDNS response, then you cannot trust the response itself and its
> indication that the domain was blocked for whatever reason, and possibly
> you cannot trust any DNS response whatsoever. In any case, it might be that
> clients will only use that information if it is received over an
> authenticated channel (e.g. via DoH).
>

https://tools.ietf.org/html/draft-reddy-dnsop-error-page-02#section-6 mandates
DoH/DoT to process the error page URL.

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 28 Jul 2020 15:07:09 +0000

paul> let me state for the record that ted's opposition was to something i hadn't proposed...

Fair enough.

paul> when DoH is going to be denied, i'd like the node to get an accurate signal
about that, rather than silent failure

We agree on this point. My point from before is that this signal should be 1) not specific to DoH as there are other pre-existing encrypted communication flows which could use this same new mechanism, and 2) authenticated such that a client can strongly determine the signal came from a network administrator for the network the client joined as opposed to an on-path attacker. Based on my point of view, such a mechanism should be designed outside the ADD WG.

paul> but to repeat, what do you want to see happen during administrative denials?
right now it's unexplained silence and failure. i think that's bad customer
service, and i want us to strive for better.

Before DoH, this was also unexplained silence and failure. The DNS packets would be dropped and the device would see no connectivity until the DNS settings were changed by the user. Adding DoH to the mix doesn't change that customer support story. Users configuring public resolvers, encrypted or not, will continue to see a lack of Internet connectivity when on a network which blocks off-network DNS flows, encrypted or not. The only difference is when the traffic is unencrypted, the network can attack the traffic and either 1) resolve the queries itself, or 2) return a false result to send browsers to a page explaining the situation.

Allowing either of those approaches to also work for DoH or DoT would destroy the value of encrypted communication as they require the network to be able to speak as if it were the endpoint the client was trying to reach. Instead, we would need a network-originating signal referring to the prohibited communication channel. To my knowledge, this doesn't exist with authentication to a recognized network authority. This circles back to my point above about needing a larger-than-DoH-and-ADD-WG mechanism for networks to securely indicate to clients when their network flows are forbidden.

Thanks,
Tommy Jensen
================================================
The latest in Windows Internet Protocols:
  Native gRPC support: https://aka.ms/grpcblogpost
  DNS over HTTPS: https://aka.ms/dohblogpost
________________________________
From: Add <[email-masked]> on behalf of Paul Vixie <[email-masked]>
Sent: Tuesday, July 28, 2020 12:34 AM
To: [email-masked] <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: New Version Notification for draft-pauly-add-resolver-discovery-01.txt

--
Paul

--
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%7C4b243c0abce042f2c36208d832c8b641%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315184929971483&amp;sdata=AXdClv1hufFXgGPdtDXaQ0zoOS%2BoQxdEkO5QhHn0YCc%3D&amp;reserved=0

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 28 Jul 2020 15:17:00 +0000

vittorio> On the other hand, refusing to standardize such a mechanism would be quite a strong policy stance, as it would assume that all networks will always be adversarial and badly intentioned so there is no use in even listening to what they would like to say.

Would it though? Before DoH and DoT, all common DNS clients (loosely defined as OSes as browsers weren't in the game yet) ignored network recommended browsers the moment the user provided a public resolver to use instead. That wasn't treating networks as adversarial; that was because the network recommendation was just that, not a requirement. I don't think it would be a strong policy stance for the IETF to not standardize a change to that.

To be clear, I'm in favor of providing networks a way to indicate they don't want clients using other DNS servers if we can do so securely such that it can be differentiated from an attacker. This however would be a new network-client contract that IMO should be larger than DNS (See my response to Paul), and not defining such a mechanism shouldn't be controversial. Clients can still choose to use network recommended servers if they want just as before.

Thanks,
Tommy Jensen

________________________________
From: Add <[email-masked]> on behalf of Vittorio Bertola <vittorio.bertola=[email-masked]>
Sent: Tuesday, July 28, 2020 4:33 AM
To: Ted Lemon <[email-masked]>; Paul Vixie <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: New Version Notification for draft-pauly-add-resolver-discovery-01.txt

Why?

--
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%7C809c524d03914d578d3608d832ea2101%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315328442891611&amp;sdata=I6BdZuOvjKIrHdy6WqjA0hgcu9AYjqyLCy9yRnhqJkU%3D&amp;reserved=0

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Jul 2020 17:24:31 +0200

On Tue, Jul 28, 2020 at 03:17:00PM +0000,
 Tommy Jensen <Jensen.Thomas=[email-masked]> wrote 
 a message of 310 lines which said:

> To be clear, I'm in favor of providing networks a way to indicate
> they don't want clients using other DNS servers if we can do so
> securely such that it can be differentiated from an attacker. This
> however would be a new network-client contract that IMO should be
> larger than DNS

And it seems a job for PvD (draft-ietf-intarea-provisioning-domains).

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Jul 2020 11:46:51 -0400

On Jul 28, 2020, at 10:31 AM, Vittorio Bertola <[email-masked]> wrote:
> Of course that requires some security considerations and validation before use, but if you assume that you cannot trust the (https) URL indicated in the EDNS response, then you cannot trust the response itself

I think that’s what I said, yet.

> and its indication that the domain was blocked for whatever reason, and possibly you cannot trust any DNS response whatsoever. In any case, it might be that clients will only use that information if it is received over an authenticated channel (e.g. via DoH).

If I try to establish a TLS connection and get a TLS alert that says “TLS is blocked except when you allow me to MiTM your TLS connection,” then I know that I can’t use the network without installing the TLS cert I need to successfully be MiTM’d. This is perfectly fine, sort of.

However, if the next thing that pops up is a web page explaining how to install the TLS cert, with a download link, then that’s not fine, because a naive end user will just follow the instructions. This is a situation where giving you, the well-intentioned network operator, an opportunity to explain yourself creates an attack surface that will be exploited by malware.

This is why browsers are moving toward not even telling you how to bypass “self-signed cert” warnings. It’s just not safe to tell the end user how to do that. If they need to do that, either they know how to do it, or the legitimate operator of their network knows how.

---

From: tirumal reddy <[email-masked]>
Date: Tue, 28 Jul 2020 16:01:52 +0000

> And it seems a job for PvD (draft-ietf-intarea-provisioning-domains).

The above draft is using RA to learn the PVD ID FQDN and cannot identify if
the information is indeed provided by the network or by an attacker. You
may want to look into the Security Considerations section in the draft.

-Tiru

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Tue, 28 Jul 2020 16:34:29 +0000

On Tue, Jul 28, 2020 at 03:17:00PM +0000,
 Tommy Jensen <Jensen.Thomas=[email-masked] <mailto:[email-masked]> > wrote 
 a message of 310 lines which said:

> a new network-client contract that IMO should be
> larger than DNS

+1

I describe this very problem on LI in terms of your classic Enterprise (both VPN and on-prem use cases).

*	Enterprise Network operators are not Endpoint Device Managers.  They often have no control over a device or minimal controls.
*	Enterprise Network operators view Endpoints as risks.
*	Endpoints view Networks as risks.
*	Enterprise Network operators will block things at a Network layer that they can’t control / manage.  It is just how it is. 
For example, It is not uncommon for an Enterprise policy to block social networks, tor, etc.  A 3rd party cloud DNS resolver would not be treated  differently imho.

Any solution proposed has to allow discovery to be trusted and for the Enterprise Network operator to enforce policies.  

If the two entities (network-client) can’t agree, then some way of usefully expressing that to the user needs to be considered.  

Maybe this is at the time a network is joined (hence advertising capabilities via DHCP / RA might be a logical path ).

All of this might be outside the scope of ADD – but it still needs to be solved.

---

From: "Robert Mortimer" <[email-masked]>
Date: Tue, 28 Jul 2020 18:30:44 +0100

+1 

There has to be a user-network negotiation. If they agree stuff works - if they don't the user declines to connect to the network.

How that's achieved if we assume that users can't be trusted to make decision as they won't understand the question and anyway the network might be lying is obviously gong to be tricky. I think if you decide the user can't be trusted and remove their agency then we're probably on a hiding to nothing ( and this seems to be the direction at least a few people want to head in ).

-- 
Robm
873
  "Ask not what I can do for the stupid, 
         but what the stupid can do for me" - Graeme Garden
On 28/07/2020 12:35:03, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:

> Il 28/07/2020 12:39 Ted Lemon ha scritto:
>
>
> > On Jul 28, 2020, at 03:34, Paul Vixie wrote:

Why?

---

From: Kenji Baheux <[email-masked]>
Date: Wed, 29 Jul 2020 11:30:34 +0900

On Tue, Jul 28, 2020 at 11:50 PM tirumal reddy <[email-masked]> wrote:

>> Of course that requires some security considerations and validation
>> before use, but if you assume that you cannot trust the (https) URL
>> indicated in the EDNS response, then you cannot trust the response itself
>> and its indication that the domain was blocked for whatever reason, and
>> possibly you cannot trust any DNS response whatsoever. In any case, it
>> might be that clients will only use that information if it is received over
>> an authenticated channel (e.g. via DoH).
>>
>

As part of the set of considerations / validations, I've been thinking that
a client would only consider surfacing a URL present in an EDNS response if
it matches with / relates to the DoH service in use. Is that a useful
distinction, are there other issues?

-- 
Kenji BAHEUX
Product Manager - Chrome
Google Japan

---

From: Paul Vixie <[email-masked]>
Date: Wed, 29 Jul 2020 04:07:34 +0000

On Wednesday, 29 July 2020 02:30:34 UTC Kenji Baheux wrote:
> > https://tools.ietf.org/html/draft-reddy-dnsop-error-page-02#section-6
> > mandates DoH/DoT to process the error page URL.
> 
> it matches with / relates to the DoH service in use.

the normal way to do this is to make the URI error signal a separate option, 
and to have the client include it (empty) if it wants the server to fill it 
in.

> Is that a useful distinction, are there other issues?

by default, nothing in DNS should presume the existence of the web. options 
for this may be useful, but only when negotiated.

-- 
Paul

---

From: tirumal reddy <[email-masked]>
Date: Wed, 29 Jul 2020 05:21:01 +0000

On Wed, 29 Jul 2020 at 02:30, Kenji Baheux <[email-masked]> wrote:

>>> What is still missing is a standard way for the resolver to communicate
>>> a URL to the client in the response, so that the client (if it wants) can
>>> use it to retrieve and display a human-readable error message.
>>>
>>>
> As part of the set of considerations / validations, I've been thinking
> that a client would only consider surfacing a URL present in an EDNS
> response if it matches with / relates to the DoH service in use. Is that a
> useful distinction, are there other issues?
>

Yes, it is useful. If the DoH service does not offer filtering (e.g.,
blocking malware), the error page URL will be rejected by the client.

-Tiru

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 29 Jul 2020 07:21:30 +0000

Both the drafts only validate what Tommy said 'You need some prior knowledge and trust of the network'.

draft-reddy-add-iot-byod-bootstrap: section 4 says "The endpoint authenticates to the local network and discovers the Enrollment over Secure Transport (EST)" and also "the endpoint MUST authenticate the EST server before it accepts the DNS server certificate.". This implies that you need some prior knowledge of the network to establish trust. Section 5 does a complex indirection and instead of directly authenticating the network, it relies on the manufacturer to confirm if the network is correct.

draft-btw-add-ipsecme-ike: you need some credentials for setting up the IPSec tunnel.

--Mohit

On 7/28/20 3:23 PM, tirumal reddy wrote:
On Tue, 28 Jul 2020 at 00:44, Tommy Jensen <Jensen.Thomas=[email-masked]<mailto:[email-masked]>> wrote:
(+1 to ekr's point)

I agree with Ted: we shouldn't go weakening strong end-to-end encrypted protocols on purpose. From an endpoint's perspective, there is no authoritative way to distinguish between network administration ("good") and network attacks ("bad") without some prior knowledge and trust of the network, such as preinstalled certificates.

Secure discovery is possible in several scenarios and the client can identify/authenticate the local DoH/DoT server, for example see https://tools.ietf.org/html/draft-reddy-add-iot-byod-bootstrap-01<https://tools.ietf.org/html/draft-reddy-add-iot-byod-bootstrap-00> and https://tools.ietf.org/html/draft-btw-add-ipsecme-ike-00. In deployments where secure discovery is not possible, client validation techniques like pre-configured TRR or cryptographic assertion of the DNS server identity would ensure the client does not connect to an attacker's DoH/DoT server.

Arguably, these networks which want to tightly control network behavior ought to tightly control network joining capabilities to prevent this perceived misbehavior. Otherwise, any side door we build for MitM to more readily block/downgrade communication between intended endpoints will be a side door attackers can use as well.

IT-managed endpoint devices can be tightly controlled by management software but not BYOD (without MDM/configuration profile). In deployments like home networks, the network security service co-located in the home router has no way to manage or tightly control endpoint and IoT devices.

-Tiru

Thanks,
Tommy Jensen
================================================
The latest in Windows Internet Protocols:
  Native gRPC support: https://aka.ms/grpcblogpost
  DNS over HTTPS: https://aka.ms/dohblogpost
________________________________
From: Add <[email-masked]<mailto:[email-masked]>> on behalf of Ted Lemon <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 27, 2020 5:27 PM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Paul Vixie <[email-masked]<mailto:[email-masked]>>; STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; Rob Sayre <sayrer@gmail..com><mailto:sayrer@gmail..com>
Subject: [EXTERNAL] Re: [Add] New Version Notification for draft-pauly-add-resolver-discovery-01.txt

On Jul 27, 2020, at 8:11 PM, Eric Rescorla <[email-masked]<mailto:ekr@rtfm..com>> wrote:

---

From: tirumal reddy <[email-masked]>
Date: Wed, 29 Jul 2020 09:39:32 +0000

On Wed, 29 Jul 2020 at 07:21, Mohit Sethi M <[email-masked]>
wrote:

> draft-reddy-add-iot-byod-bootstrap: section 4 says "The endpoint
> authenticates to the local network and discovers the Enrollment over Secure
> Transport (EST)" and also "the endpoint MUST authenticate the EST server
> before it accepts the DNS server certificate.". This implies that you need
> some prior knowledge of the network to establish trust. Section 5 does a
> complex indirection and instead of directly authenticating the network, it
> relies on the manufacturer to confirm if the network is correct.
>
Section 5 is specific to bootstrapping IoT devices only and steps 1 to 3 in
Section 5 are part of BRSKI (see
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-41) to
complete bi-directional authentication of the IoT device and the network.
Step 4 to 5 are defined in draft-reddy-add-iot-byod-bootstrap to securely
discover the local DoH/DoT server using the EST server.

-Tiru

>> If we want to allow networks to give new and arbitrary endpoints a
>> trusted (defined as "client can securely distinguish from an arbitrary
>> attacker") signal that a given communication mechanism is forbidden, we
>> (not this WG) should work on that on a larger scale. After all, such a
>> mechanism could be used to signal network opposition to VPN tunnels, Tor
>> connections, or anything else a network find offensive. If it works for
>> HTTPS, DoH should inherit the benefits gracefully.
>>
>> to detect specific network environments (such as captive portal and
>> split horizon) and to use that information to inform their DNS
>> configuration.
>>
>> Thanks,
>> Tommy Jensen
>> <sayrer@gmail..com>
>> Okay, fair point, DoH can just be a better protocol as well as being a
>> way to get privacy. A better way to have put that would be that making DoH
>> easy to detect blocks one of the main benefits of DoH: that it gives the
>> user privacy from on-path snoopers in a way that can’t be easily blocked.
>>
>>
>> --
>> Add mailing list
>> [email-masked]

---

From: tirumal reddy <[email-masked]>
Date: Wed, 29 Jul 2020 10:23:40 +0000

On Tue, 28 Jul 2020 at 15:47, Ted Lemon <[email-masked]> wrote:

> On Jul 28, 2020, at 10:31 AM, Vittorio Bertola <
> [email-masked]> wrote:
>
> the EDNS response, then you cannot trust the response itself
>
>
> If I try to establish a TLS connection and get a TLS alert that says “TLS
> is blocked except when you allow me to MiTM your TLS connection,” then I
> know that I can’t use the network without installing the TLS cert I need to
> successfully be MiTM’d. This is perfectly fine, sort of.
>

TLS alert is an authenticated message and cannot be generated by the
network security service. Manually installing a local root certificate
means the middle-box can act as a TLS proxy even if it only performs DNS
filtering.

The idea is not to install a local root certificate for the error page URL.

>
> However, if the next thing that pops up is a web page explaining how to
> install the TLS cert, with a download link, then that’s not fine, because a
> naive end user will just follow the instructions. This is a situation where
> giving you, the well-intentioned network operator, an opportunity to
> explain yourself creates an attack surface that will be exploited by
> malware.
>

You may want to look into
https://tools.ietf.org/html/draft-reddy-dnsop-error-page-02#section-6. The
HTTPS record conveying the error page URL will only be processed along with
"Forged answer" error code and DoH or DoT (in strict privacy mode) is
mandatory. An attacker cannot modify the DNS response to insert a malware
URL.

>
> This is why browsers are moving toward not even telling you how to bypass
> “self-signed cert” warnings. It’s just not safe to tell the end user how to
> do that. If they need to do that, either they know how to do it, or the
> legitimate operator of their network knows how.
>

"Advanced" setting is available on most browsers today to by-pass the
warning and proceed. The proposed mechanism helps avoid training users to
click through certificate errors.

Cheers,
-Tiru

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 29 Jul 2020 12:37:55 +0200 (CEST)

>     Il 28/07/2020 17:46 Ted Lemon <[email-masked]> ha scritto:
>      
> 
>     If I try to establish a TLS connection and get a TLS alert that says “TLS is blocked except when you allow me to MiTM your TLS connection,”
> 
This is not the use case for extended DNS errors, which are sent in response to a DNS query and not to the establishment of the TLS connection. The use case is when you have already started to use a resolver (encrypted or not, though the security of transport may play a role in deciding whether to accept the signal or not), you want to connect to a specific destination, you query the resolver for the IP address and the resolver tells you "you are not allowed to connect to that server". Today, this usually happens via a NXDOMAIN which gives you an error and that's it; there used to be services that would rather redirect you to a proxy with a human-readable error page by giving you its IP address in the response, but that doesn't work with HTTPS and doesn't work if the application is not the web.

So the idea is that, rather than just breaking everything, the resolver will send you a response which includes one of the three "blocked" error codes (depending on the reason for blocking) and a proper, PKI-valid HTTPS URL on the local network operator's website where the client can get the human-readable message from.

--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Jul 2020 07:40:44 -0400

On Jul 29, 2020, at 6:23 AM, tirumal reddy <[email-masked]> wrote:
> TLS alert is an authenticated message and cannot be generated by the network security service. Manually installing a local root certificate means the middle-box can act as a TLS proxy even if it only performs DNS filtering. 

Not true. A TLS alert can be sent in response to a ClientHello.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Jul 2020 07:43:52 -0400

> So the idea is that, rather than just breaking everything, the resolver will send you a response which includes one of the three "blocked" error codes (depending on the reason for blocking) and a p…

Here you are talking about the situation where a DoH server has been discovered and a connection to the DoH server has been made, and authenticated, and the client trusts the DoH server. At this point the DoH server makes an assertion about a query the user has made, and responds with information about why the query was blocked.  This is okay, if trust has actually been established. If a non-trusted DoH server returned this response, it would be inappropriate to display it to the end user, because it would represent an attack surface in this case.

The big rhinoceros in the room here, of course, is what it means to “establish trust” with a previously unknown DoH server.

---

From: tirumal reddy <[email-masked]>
Date: Wed, 29 Jul 2020 12:01:09 +0000

On Wed, 29 Jul 2020 at 11:44, Ted Lemon <[email-masked]> wrote:

> On Jul 29, 2020, at 6:37 AM, Vittorio Bertola <
> is blocked except when you allow me to MiTM your TLS connection,”
>
> This is not the use case for extended DNS errors, which are sent in
> response to a DNS query and not to the establishment of the TLS connection.
> The use case is when you have already started to use a resolver (encrypted
> or not, though the security of transport may play a role in deciding
> whether to accept the signal or not), you want to connect to a specific
> destination, you query the resolver for the IP address and the resolver
> tells you "you are not allowed to connect to that server". Today, this
> usually happens via a NXDOMAIN which gives you an error and that's it;
> there used to be services that would rather redirect you to a proxy with a
> human-readable error page by giving you its IP address in the response, but
> that doesn't work with HTTPS and doesn't work if the application is not the
> web.
>
> So the idea is that, rather than just breaking everything, the resolver
> will send you a response which includes one of the three "blocked" error
> codes (depending on the reason for blocking) and a proper, PKI-valid HTTPS
> URL on the local network operator's website where the client can get the
> human-readable message from.
>
>
> Here you are talking about the situation where a DoH server has been
> discovered and a connection to the DoH server has been made, and
> authenticated, and the client trusts the DoH server. At this point the DoH
> server makes an assertion about a query the user has made, and responds
> with information about why the query was blocked.  This is okay, if trust
> has actually been established. If a non-trusted DoH server returned this
> response, it would be inappropriate to display it to the end user, because
> it would represent an attack surface in this case.
>

Yes, we are on the same page :)

-Tiru

>
> The big rhinoceros in the room here, of course, is what it means to
> “establish trust” with a previously unknown DoH server.
>
> --
> Add mailing list
> [email-masked]

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 29 Jul 2020 14:49:47 +0200 (CEST)

>     Il 28/07/2020 17:17 Tommy Jensen <jensen.thomas=[email-masked]> ha scritto:
>      
>      
I don't have a problem with clients deciding to ignore the locally recommended resolver (or better, if I have a problem with that, it is only when doing so breaks stuff or centralizes the Internet, and it is a policy problem rather than a technical one).

The problem I have is if the IETF decides not to even provide a way for the local network to recommend a DoH resolver.

>     To be clear, I'm in favor of providing networks a way to indicate they don't want clients using other DNS servers if we can do so securely such that it can be differentiated from an attacker. T…
That's also a useful idea (a new one, I agree), and I would be happy to contribute to it, even in other groups. However IMHO then we need something that can be deployed in the next few months as a DNS-specific stopgap measure, to allow the >60% of the world (according to the latest APNIC Labs stats) that happily uses the local resolver to migrate easily and quickly from Do53 to DoH without changing resolver. After that, we could engage in longer term work on protocols to support policy negotiations between networks and applications.

--

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 29 Jul 2020 15:33:45 +0200

On Tue, Jul 28, 2020 at 04:01:52PM +0000,
 tirumal reddy <[email-masked]> wrote 
 a message of 54 lines which said:

> > And it seems a job for PvD 
> 
> The above draft is using RA to learn the PVD ID FQDN and cannot
> identify if the information is indeed provided by the network or by
> an attacker.

PvD is a concept that goes beyond that. RFC 8801 provides a way to
learn the PvD ID by RA but other methods may appear. My point was that
this issue of discovering access network preferences should be done in
the general PvD framework.

---

From: Simon Hicks <[email-masked]>
Date: Tue, 28 Jul 2020 19:04:48 +0100

Our main aim for government is to get stable networks that work well for
all society and industry.  So we'd like to see the whole community talking
with each other and all parts of the chain working with each other to
provide chains that work well. If that doesn't happen then the next step is
regulation.  Open standards and open markets are a privilege as well as a
way of working.  If they're not working well then society reflected by
governments has to try and make them work.

Enough of the philosophy. But get a solution in this room, ie standards, or
else others will be making decisions for you.

Regards
Simon

On Tue, 28 Jul 2020 at 18:32, Robert Mortimer <robm=
[email-masked]> wrote:

> +1
>
> There has to be a user-network negotiation. If they agree stuff works - if
> they don't the user declines to connect to the network.
>
> How that's achieved if we assume that users can't be trusted to make
> decision as they won't understand the question and anyway the network might
> be lying is obviously gong to be tricky. I think if you decide the user
> can't be trusted and remove their agency then we're probably on a hiding to
> nothing ( and this seems to be the direction at least a few people want to
> head in ).
>
> --
> Robm
> 873
> On 28/07/2020 12:35:03, Vittorio Bertola <vittorio.bertola=
> > That’s not the concern. The concern is that if DoH traffic is labeled
> specifically so that the network can identify it, it will be blocked,
>
> Why?
>
> There will be networks that want to block DoH, and there will be others
> that don't, and there will be others that will say that you can have DoH
> but only if you use the local resolver, or if you use a resolver from a
> specific list, or will suggest you a local resolver but then accept a
> different choice.
>
> Then, there will be clients (both on behalf of the user, i.e. anonymizing
> browsers, and against the user, i.e. malware) that will want to ignore that
> policy if they dislike it, and do something else - and there will be
> networks that will then react by doing all sorts of bad things to traffic
> from those clients.
>
> We cannot do much in the case when clients (users) and networks (network
> providers) disagree, and that case will always exist, but there is a number
> of use cases (hopefully most of them) in which users and network providers
> will cooperate to find a mutually acceptable configuration. What we should
> develop is a way for the client to discover the local DoH resolver's
> location and the network policy attached to it, so that the above agreement
> becomes possible in those cases. What the client does with that
> information, and whether the client chooses to abide by or defy the local
> policy, will then be a choice for the developers of each client (and for
> their lawyers and policy officers, I suspect, but that's another
> discussion).
>
> On the other hand, refusing to standardize such a mechanism would be quite
> a strong policy stance, as it would assume that all networks will always be
> adversarial and badly intentioned so there is no use in even listening to
> what they would like to say. I don't think that the IETF should go down
> that path.
>
> --

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 29 Jul 2020 16:04:09 +0000

simon> So we'd like to see the whole community talking with each other and all parts of the chain working with each other to provide chains that work well

That's what is happening. Everyone here wants a well-functioning ecosystem. Our disagreements and discussions aren't evidence that we don't; they're evidence that we all have different perspective that require time and deliberation to work through.

If there are concrete features that define "chains that work well" you're not seeing in our current drafts, please share. Vittorio changed my thinking with regards to government requirements just this morning (afternoon?) in DNSOP by providing a concrete use case for Italian DNS handling.

Thanks,
Tommy Jensen
================================================
The latest in Windows Internet Protocols:
  Native gRPC support: https://aka.ms/grpcblogpost
  DNS over HTTPS: https://aka.ms/dohblogpost
________________________________
From: Add <[email-masked]> on behalf of Simon Hicks <[email-masked]>
Sent: Tuesday, July 28, 2020 11:04 AM
To: Robert Mortimer <robm=[email-masked]>
Cc: ADD Mailing list <[email-masked]>; Vittorio Bertola <vittorio.bertola=[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: New Version Notification for draft-pauly-add-resolver-discovery-01.txt

Our main aim for government is to get stable networks that work well for all society and industry.  So we'd like to see the whole community talking with each other and all parts of the chain working with each other to provide chains that work well. If that doesn't happen then the next step is regulation.  Open standards and open markets are a privilege as well as a way of working.  If they're not working well then society reflected by governments has to try and make them work.

Enough of the philosophy. But get a solution in this room, ie standards, or else others will be making decisions for you.

Regards
Simon

On Tue, 28 Jul 2020 at 18:32, Robert Mortimer <robm=[email-masked]<mailto:[email-masked]>> wrote:
+1

Why?

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

--
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%7C2a73bc392c534cf4447308d833d3e018%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316333134057642&sdata=8Q5NoEeOgeCWyvhEjSag33Zdy6Yb2shz75%2FFLyk8tqE%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%7C2a73bc392c534cf4447308d833d3e018%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316333134057642&sdata=8Q5NoEeOgeCWyvhEjSag33Zdy6Yb2shz75%2FFLyk8tqE%3D&reserved=0>

---

From: Andrew Campling <[email-masked]>
Date: Wed, 29 Jul 2020 16:10:04 +0000

Noting Simon’s and Rob’s comments below, it would be helpful to focus on ways to implement discovery that might be reasonably expected to work for the users* of the network architectures that are commonly deployed, and in particular to make sure that things work as smoothly as possible from the perspective of those users.  I believe that this would be consistent with the paper discussed at the IAB open meeting yesterday – see draft-iab-for-the-users-04, which states “when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favour end users”.  As Rob comments, I think if you decide the user can't be trusted and remove their agency then we're probably on a hiding to nothing.

My concern is that some approaches appear to be mandating the delegation of control to the client software or other mechanisms not involving the user.  I don’t believe that this is the correct approach, fear it may struggle regarding GDPR compliance and certainly seems at odds with the IAB document.  I may of course be misunderstanding what people are trying to achieve.

Andrew

* NB “Users” may of course include entities other than end users that have a reasonable expectation of control, including enterprises, parents, private network operators etc.

From: Simon Hicks <[email-masked]>
Sent: 28 July 2020 19:05
To: Robert Mortimer <robm=[email-masked]>
Cc: ADD Mailing list <[email-masked]>; Vittorio Bertola <vittorio.bertola=[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: New Version Notification for draft-pauly-add-resolver-discovery-01.txt

Regards
Simon

Why?

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 29 Jul 2020 16:50:33 +0000

Hey Andrew,

Can you be specific about your GDPR concerns? Each time I press on what parts of the proposals run afoul of GDPR, here or in other DNS bodies, I'm told "talk to your lawyer" which, to be fair, is a valid answer. However, if there are not specific technical concerns that can be shared on list, I don't think we should block standard design on the vague legal risk that _might_ exist. Let's be specific about the GDPR concerns.

Regarding user choice, keep in mind policy decisions are out of scope for this WG charter. In addition, protocols we develop here don't block policy decisions. It's possible for a client to implement any or all of the proposals listed here and then turn around and make them all controllable by a UX, or a policy, or whatever else.

Can you be specific about any standard proposal which _precludes_ an implementation from offerings user/admin/enterprise/etc. choice and control or regresses control from what they have today? I don't think there's a single draft that's trying to decide a conflict of interest "between the interests of end users of the Internet and other parties" in favor of the latter instead of the former. If I'm wrong, please help me understand which drafts aren't favoring end users interests and how they aren't.

Thanks,
Tommy Jensen
================================================
The latest in Windows Internet Protocols:
  Native gRPC support: https://aka.ms/grpcblogpost
  DNS over HTTPS: https://aka.ms/dohblogpost
________________________________
From: Add <[email-masked]> on behalf of Andrew Campling <[email-masked]>
Sent: Wednesday, July 29, 2020 9:10 AM
To: Simon Hicks <[email-masked]>; Robert Mortimer <robm=[email-masked]>; Vittorio Bertola <vittorio.bertola=[email-masked]>; Ted Lemon <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: New Version Notification for draft-pauly-add-resolver-discovery-01.txt

Andrew

Regards
Simon

+1

--

Robm

873

Why?

--
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%7C558c75f214744daca67608d833da0d6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316358920522077&sdata=KdiQKZa8CGiCZLbw9UYmpxQ%2Fhw4ptudbkZlWQTvb%2FRY%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%7C558c75f214744daca67608d833da0d6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637316358920532070&sdata=hQOwryIFVnjC5X7CkK%2BXsBV0QY6JQlt%2B6xc8n1RLSEg%3D&reserved=0>

---

From: "Chris Box (BT)" <[email-masked]>
Date: Wed, 29 Jul 2020 17:59:45 +0100

This question of who represents the "user" we aim to support is
frustratingly hard to pin down.

IAB-for-the-users acknowledges it includes people *not *using the client
device in question, naming both parents and other people in a photograph or
room.

Chris

On Wed, 29 Jul 2020 at 17:11, Andrew Campling
<[email-masked]> wrote:

> Noting Simon’s and Rob’s comments below, it would be helpful to focus on
> ways to implement discovery that might be reasonably expected to work for
> the users* of the network architectures that are commonly deployed, and in
> particular to make sure that things work as smoothly as possible from the
> perspective of those users.  I believe that this would be consistent with
> the paper discussed at the IAB open meeting yesterday – see draft-iab-for-the-users-04,
> which states “when there is a conflict between the interests of end users
> of the Internet and other parties, IETF decisions should favour end
> users”.  As Rob comments, I think if you decide the user can't be trusted
> and remove their agency then we're probably on a hiding to nothing.
>
>
>
> My concern is that some approaches appear to be mandating the delegation
> of control to the client software or other mechanisms not involving the
> user.  I don’t believe that this is the correct approach, fear it may
> struggle regarding GDPR compliance and certainly seems at odds with the IAB
> document.  I may of course be misunderstanding what people are trying to
> achieve.
>
>
>
>
>
> *Andrew *
>
>
>
> * NB “Users” may of course include entities other than end users that have
> a reasonable expectation of control, including enterprises, parents,
> private network operators etc.
>
>
>

---

From: "Chris Box (BT)" <[email-masked]>
Date: Wed, 29 Jul 2020 18:44:14 +0100

On Wed, 29 Jul 2020 at 17:50, Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> Can you be specific about any standard proposal which _precludes_ an
> implementation from offerings user/admin/enterprise/etc. choice and control
> or regresses control from what they have today? I don't think there's a
> single draft that's trying to decide a conflict of interest "between the
> interests of end users of the Internet and other parties" in favor of the
> latter instead of the former. If I'm wrong, please help me understand which
> drafts aren't favoring end users interests and how they aren't.
>
>
Surely Adaptive DNS's concept of learning the designated resolver for a
domain will, by default, regress parent control of child devices,
particularly in the widely deployed scenario where the parent asks the
network provider to do this job. This is true unless there is also (a) a
standardised way for the network to inform the device of policy, and (b)
common client implementations honor this.

I used the parent example as this is mentioned in IAB-for-the-users, but
could equally apply to the area of trying to stop your IoT devices from
doing things they shouldn't.

This could well be a timing issue. To avoid serious regressions I think we
need a coherent set of drafts that support all possible use cases before
going to mainstream deployment. Deploying domain designation by itself, or
many other single drafts, will inevitably break some things.

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 29 Jul 2020 18:26:03 +0000

Hey Chris,

Thanks for the scenario. Allow me to try and address it using our draft.

For the parental control scenario, there are two scenarios I can think of. One is the ISP is recommending a DNS server to network members with a public address. By deploying DoH in accordance with the draft to that server, the situation self resolves. The client will follow section 5, make a DoH connection to the server, then the server can proceed how it sees fit. This may include DNS manipulation to serve an interest such as parental controls, including filtering SVCB record to prevent Adaptive DNS from discovering new DoH designations that would take it away from the parental filtering server.

The other scenario is the ISP recommends an RFC1918 address, which the draft doesn't directly address. This is a situation where the standard shouldn't be confused with an implementation. Section 7 calls out that a client can use its own discretion and policy when falling back to classic DNS though the example context is different. Where Adaptive DNS is intended to be a strong privacy offering, it makes sense some users (in this case, admins who are parents) may use device configuration to choose between privacy and content filtering functionality.  The same SVCB record manipulation possibility exists.

With this context, my view on your parental filtering concern is really a request to not have Adaptive DNS be on by default, which is an implementation policy concern and not a standards detail. For example, TLS 1.3 being the minimum version required everywhere would immediately break many sites, and requiring DNSSEC validation at the client would break many sites. That doesn't make either of these standards bad ideas, just that there are contexts implementors of each need to be aware of when rolling out bits.

To be clear, I don't like the idea of the network attacking the SVCB records. However, it is possible and isn't a regression from today where DNS packets are attacked to provide redirection to "censored" pages. A user seeing this who isn't ok with the filtering can take manual action to bootstrap with a trusted DoH server. A user who is ok will happily continue as they did before Adaptive rollad out. In your scenario, the "user" is ok with it and would experience no regressions unless they take action to configure a DoH server other than yours, which would be a user signal that they actually don't want filtering.

Thoughts?

Thanks,
Tommy Jensen

________________________________
From: Chris Box (BT) <[email-masked]>
Sent: Wednesday, July 29, 2020 10:44 AM
To: Tommy Jensen <[email-masked]>
Cc: Andrew Campling <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: New Version Notification for draft-pauly-add-resolver-discovery-01.txt

On Wed, 29 Jul 2020 at 17:50, Tommy Jensen <Jensen.Thomas=[email-masked]..org<mailto:[email-masked]>> wrote:
Can you be specific about any standard proposal which _precludes_ an implementation from offerings user/admin/enterprise/etc. choice and control or regresses control from what they have today? I don't think there's a single draft that's trying to decide a conflict of interest "between the interests of end users of the Internet and other parties" in favor of the latter instead of the former. If I'm wrong, please help me understand which drafts aren't favoring end users interests and how they aren't.

Surely Adaptive DNS's concept of learning the designated resolver for a domain will, by default, regress parent control of child devices, particularly in the widely deployed scenario where the parent asks the network provider to do this job. This is true unless there is also (a) a standardised way for the network to inform the device of policy, and (b) common client implementations honor this.

I used the parent example as this is mentioned in IAB-for-the-users, but could equally apply to the area of trying to stop your IoT devices from doing things they shouldn't.

This could well be a timing issue. To avoid serious regressions I think we need a coherent set of drafts that support all possible use cases before going to mainstream deployment. Deploying domain designation by itself, or many other single drafts, will inevitably break some things.

---

From: "Chris Box (BT)" <[email-masked]>
Date: Wed, 29 Jul 2020 21:27:57 +0100

Tommy,

Like you I would rather not resort to SVCB filtering; it’s a poor way of
advising the client what the network would like.

I think I’ll reiterate the plea that implementations hold fire on mass
deployments that break things until there is an agreed way to communicate
information that allows policies, preferences etc to work. I’m initially
looking at ADD to provide this, but I could equally see this could be
broader than DNS. Unfortunately Apple is racing ahead of this, generating
the collateral damage that probably gives rise to Simon’s frustration. I
know that’s not your responsibility, and Windows is deploying at a more
measured pace.

Encrypted DNS is an excellent idea but challenging to deploy across all use
cases. Having a coherent set of drafts will be needed. The Adaptive DNS
draft still has a lot to offer, and seems pretty well designed, but we need
others in the picture too.

Chris

On Wed, 29 Jul 2020 at 19:26, Tommy Jensen <[email-masked]>
wrote:

> For the parental control scenario, there are two scenarios I can think of.
> One is the ISP is recommending a DNS server to network members with a
> public address. By deploying DoH in accordance with the draft to that
> server, the situation self resolves. The client will follow section 5, make
> a DoH connection to the server, then the server can proceed how it sees
> fit. This may include DNS manipulation to serve an interest such as
> parental controls, including filtering SVCB record to prevent Adaptive DNS
> from discovering new DoH designations that would take it away from the
> parental filtering server.
>
> The other scenario is the ISP recommends an RFC1918 address, which the
> draft doesn't directly address. This is a situation where the standard
> shouldn't be confused with an implementation. Section 7 calls out that a
> client can use its own discretion and policy when falling back to classic
> DNS though the example context is different. Where Adaptive DNS is intended
> to be a strong privacy offering, it makes sense some users (in this case,
> admins who are parents) may use device configuration to choose between
> privacy and content filtering functionality.  The same SVCB record
> manipulation possibility exists.
>
> With this context, my view on your parental filtering concern is really a
> request to not have Adaptive DNS be on by default, which is an
> implementation policy concern and not a standards detail. For example, TLS
> 1.3 being the minimum version required everywhere would immediately break
> many sites, and requiring DNSSEC validation at the client would break many
> sites. That doesn't make either of these standards bad ideas, just that
> there are contexts implementors of each need to be aware of when rolling
> out bits.
>
> To be clear, I don't like the idea of the network attacking the SVCB
> records. However, it is possible and isn't a regression from today where
> DNS packets are attacked to provide redirection to "censored" pages. A user
> seeing this who isn't ok with the filtering can take manual action to
> bootstrap with a trusted DoH server. A user who is ok will happily continue
> as they did before Adaptive rollad out. In your scenario, the "user" is ok
> with it and would experience no regressions unless they take action to
> configure a DoH server other than yours, which would be a user signal that
> they actually don't want filtering.
>
> Thoughts?
>
> Thanks,
> Tommy Jensen
> *From:* Chris Box (BT) <[email-masked]>
> *Sent:* Wednesday, July 29, 2020 10:44 AM
> *To:* Tommy Jensen <[email-masked]>
> *Cc:* Andrew Campling <[email-masked]>; ADD Mailing list <
> [email-masked]>
>
> *Subject:* Re: [Add] [EXTERNAL] Re: New Version Notification for
> [email-masked]..org <[email-masked]>> wrote:
>

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 29 Jul 2020 20:41:12 +0000

chris> The Adaptive DNS draft still has a lot to offer, and seems pretty well designed, but we need others in the picture too

First, thank you on behalf of the other authors! Second, I can't think of a better reason to support its adoption by the WG so we can collaboratively refine it. That's how we get the whole group in the picture.

Thanks,
Tommy Jensen
Sent: Wednesday, July 29, 2020 1:27 PM
Cc: ADD Mailing list <[email-masked]>; Andrew Campling <[email-masked]>

Tommy,

Like you I would rather not resort to SVCB filtering; it’s a poor way of advising the client what the network would like.

I think I’ll reiterate the plea that implementations hold fire on mass deployments that break things until there is an agreed way to communicate information that allows policies, preferences etc to work. I’m initially looking at ADD to provide this, but I could equally see this could be broader than DNS. Unfortunately Apple is racing ahead of this, generating the collateral damage that probably gives rise to Simon’s frustration. I know that’s not your responsibility, and Windows is deploying at a more measured pace.

Encrypted DNS is an excellent idea but challenging to deploy across all use cases. Having a coherent set of drafts will be needed. The Adaptive DNS draft still has a lot to offer, and seems pretty well designed, but we need others in the picture too.

Chris

On Wed, 29 Jul 2020 at 19:26, Tommy Jensen <[email-masked]<mailto:[email-masked]>> wrote:
Hey Chris,

Thoughts?

Thanks,
Tommy Jensen

________________________________
From: Chris Box (BT) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 29, 2020 10:44 AM
To: Tommy Jensen <[email-masked]<mailto:[email-masked]>>
Cc: Andrew Campling <[email-masked]>; ADD Mailing list <[email-masked]<mailto:[email-masked]>>

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Jul 2020 13:49:22 -0700

> common client implementations honor this.

I think this use case (which I agree does occur), is where the arguments
get a bit circular. It doesn't seem possible for "the network to inform the
device of policy" in a way that is distinguishable from an attack.

thanks,
Rob

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Jul 2020 17:32:40 -0400

On Jul 29, 2020, at 4:49 PM, Rob Sayre <[email-masked]> wrote:
> I think this use case (which I agree does occur), is where the arguments get a bit circular. It doesn't seem possible for "the network to inform the device of policy" in a way that is distinguishable from an attack.

The usual way to do this is to install a device profile. I don’t know if there’s an easy way for a parent to do this to a child, though, and it’s questionable to what extent this isn’t an inappropriate violation of the child’s autonomy. Think homophobic parents, etc.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Jul 2020 14:42:06 -0700

On Wed, Jul 29, 2020 at 2:32 PM Ted Lemon <[email-masked]> wrote:

> The usual way to do this is to install a device profile. I don’t know if
> there’s an easy way for a parent to do this to a child, though, and it’s
> questionable to what extent this isn’t an inappropriate violation of the
> child’s autonomy. Think homophobic parents, etc.
>

To be clear, I am not talking about services like <
https://www.apple.com/families/>, which could include a "device profile"
and far exceed capabilities that could be controlled via DNS. I don't think
anyone is arguing about stuff like that, since it would be an inappropriate
topic for a networking WG.

The murky territory is where there is no such device control, but there are
products that have used clear-text DNS to deliver some of those features.

thanks,
Rob

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Jul 2020 17:47:32 -0400

On Jul 29, 2020, at 5:42 PM, Rob Sayre <[email-masked]> wrote:
> The murky territory is where there is no such device control, but there are products that have used clear-text DNS to deliver some of those features.

Actually I wasn’t referring to the Apple Families thing. You can just set up a profile that points your resolver somewhere. That somewhere can be a DNS filtering resolver.

But of course Apple Families would be better than that… :)

---

From: tirumal reddy <[email-masked]>
Date: Thu, 30 Jul 2020 03:52:20 +0000

On Wed, 29 Jul 2020 at 21:47, Ted Lemon <[email-masked]> wrote:

> The murky territory is where there is no such device control, but there
> are products that have used clear-text DNS to deliver some of those
> features.
>
>
> Actually I wasn’t referring to the Apple Families thing. You can just set
> up a profile that points your resolver somewhere. That somewhere can be a
> DNS filtering resolver.
>

Device profiles are typically used in Enterprise networks (for example, see
bullet 2 in
https://tools.ietf.org/html/draft-reddy-add-enterprise-00#section-5) to
bootstrap endpoints like BYOD but the on-boarding of endpoints is quite
different in home networks.

How do you propose on-board various types of endpoints (including smart TV,
chromebook, xbox etc) with device profiles in home networks  ?

-Tiru

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Jul 2020 21:09:18 -0700

On Wed, Jul 29, 2020 at 8:52 PM tirumal reddy <[email-masked]> wrote:

>
> How do you propose on-board various types of endpoints (including smart
> TV, chromebook, xbox etc) with device profiles in home networks  ?
>

Don't care. These are not high-security networks.

thanks,
Rob

---

From: tirumal reddy <[email-masked]>
Date: Thu, 30 Jul 2020 04:18:29 +0000

I am not sure how SVCB filtering would solve the problem. We may want to
take a step back to understand how home network security works today (I
work for McAfee and we offer network security services on home routers to
protect from both external and internal attacks (see
https://securehomeplatform.mcafee.com/). Several other security vendors
offer similar network security services.

DNS message are processed to provide the following security features:

a) Blocking domains based on threat data (e.g., malware, phishing). The
threat data keeps frequently updated and a domain reputation may change
from a good to a bad site. The DNS response is only modified for blocked
domains.
b) Inspect the DNS messages to filter communication with Malware Command &
Control server (e.g., TXT records are typically used to receive
instructions from C&C server, leak personal data).
c) IoT MUD https://tools.ietf.org/html/rfc8520 to permit IoT devices to
only reach intended domains
d) Anomaly detection (using ML) leveraging network telemetry (including
DNS) to identify malware on the endpoints.
e) Identifying phishing sites, DGA using Natural Language Processing kind
of techniques.

This discussion is out of scope of this WG but will help understand the
problems network security services will face with designated resolvers.

Cheers,
-Tiru

On Wed, 29 Jul 2020 at 20:28, Chris Box (BT) <[email-masked]>
wrote:

> Encrypted DNS is an excellent idea but challenging to deploy across all
> use cases. Having a coherent set of drafts will be needed. The Adaptive DNS
>> For the parental control scenario, there are two scenarios I can think
>> of. One is the ISP is recommending a DNS server to network members with a
>> *Cc:* Andrew Campling <[email-masked]>; ADD Mailing list
>> <[email-masked]>
>>
>> This could well be a timing issue. To avoid serious regressions I think
>> we need a coherent set of drafts that support all possible use cases before

---

From: tirumal reddy <[email-masked]>
Date: Thu, 30 Jul 2020 04:21:22 +0000

> Don't care. These are not high-security networks.

My point is parental control is not restricted to Apple devices and your
proposal of device profile is not solving the problem for home network
deployments.

-Tiru

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Jul 2020 21:23:12 -0700

> proposal of device profile is not solving the problem for home network

Other vendors have similar features, and the IETF is not here to design a
landscape for any product. But feel free to carry on. :)

thanks,
Rob

---

From: tirumal reddy <[email-masked]>
Date: Thu, 30 Jul 2020 04:55:02 +0000

> landscape for any product. But feel free to carry on. :)

I don't get your reply. You may want to look into
https://tools.ietf.org/html/draft-grover-add-policy-detection-00 to
understand the reasons for introducing canary domain as a stop-gap
mechanism.

Cheers,
-Tiru

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Jul 2020 23:00:32 -0700

On Wed, Jul 29, 2020 at 9:55 PM tirumal reddy <[email-masked]> wrote:

> I don't get your reply.

I agree that you don't get it.

thanks,
Rob

---

From: "Chris Box (BT)" <[email-masked]>
Date: Thu, 30 Jul 2020 07:00:42 +0100

Rob you appear to be saying you don’t need such features to secure a home
network, but I would certainly appreciate having Tiru’s (a) to (e) deployed
in my house. I don’t want the smart TV equipped with microphone and webcam
to be remotely compromised, nor any other device. Without such
network-level control, enabled by standards, my only defence is to
physically unplug the TV from the network when not in use.

Following Eva’s talk in HRPC, I’ll put myself in the shoes of a dissident
in a hostile regime. In such a case I would feel even greater need for such
security. Of course I would choose my security supplier carefully, and not
one aligned to the regime. I then need one or two devices that route
through Tor.

I fully agree the challenge is to distinguish legitimate network signals
from those of an attacker. Robustly identifying who they came from is
non-trivial, but hopefully not impossible?

Chris

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Jul 2020 23:05:51 -0700

On Wed, Jul 29, 2020 at 11:00 PM Chris Box (BT) <[email-masked]>
wrote:

> non-trivial, but hopefully not impossible
>

I wish you well :)

thanks,
Rob

---

From: Andrew Campling <[email-masked]>
Date: Thu, 30 Jul 2020 06:31:23 +0000

On Thurs, Jul 30, 2020 at 05:09 Rob Sayre <[email-masked]> wrote:
>
>> On Wed, Jul 29, 2020 at 8:52 PM tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:

How do you propose on-board various types of endpoints (including smart TV, chromebook, xbox etc) with device profiles in home networks  ?
> Don't care. These are not high-security networks.

They are not no-security networks either, otherwise why bother, for example, with encrypted DNS?

Andrew

---

From: Andrew Campling <[email-masked]>
Date: Thu, 30 Jul 2020 06:45:14 +0000

Tommy
Picking up the thread and also answering your earlier question about GDPR (noting that I am also not a lawyer!), I think that it would be highly problematic to have adaptive DNS on by default.  To expand, a user has expressed a preference for a DNS service, either through the acceptance of the ISP's service in signing their contract or by subsequently, Google or Cloudflare or Quad9 etc deliberately.  Adaptive DNS *appears* (I may have misunderstood) to make on-the-fly decisions about the DNS resolver based on recommendations received, which in turn appears to be at odds with the choice made by the user if it is on by default.

This could of course be dealt with by gaining user consent first, however it does seem that personal data is being shared and processed widely without any indication of the privacy policies in operation by the recipients.  (I could of course suggest a suitable, GDPR-compliant privacy policy but that's off-topic for this group. :-) )

Andrew

From: Tommy Jensen <[email-masked]>
Sent: 29 July 2020 19:26
To: Chris Box (BT) <[email-masked]>
Cc: Andrew Campling <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: New Version Notification for draft-pauly-add-resolver-discovery-01.txt

Hey Chris,

Thoughts?

Thanks,
Tommy Jensen

Cc: Andrew Campling <[email-masked]<mailto:[email-masked]>>; ADD Mailing list <[email-masked]<mailto:[email-masked]>>

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Jul 2020 23:48:21 -0700

On Wed, Jul 29, 2020 at 11:45 PM Andrew Campling
<[email-masked]> wrote:

> *Tommy*
>
> Picking up the thread and also answering your earlier question about GDPR
> (noting that I am also not a lawyer!)
>

Agree that you are not a lawyer.

thanks,
Rob

---

From: tirumal reddy <[email-masked]>
Date: Thu, 30 Jul 2020 12:11:47 +0000

Hi Chris,

Good points, please see inline

> non-trivial, but hopefully not impossible?

Yes, identifying the trustworthiness of the peer is discussed in RATS WG
(see https://datatracker.ietf.org/wg/rats/about/). Remote attestation
procedures (RATS) enable relying parties to establish a level of confidence
in the trustworthiness of remote system components through the creation of
attestation evidence by remote system components and a processing
chain towards the relying party. A relying party can then decide whether
to consider a remote system component trustworthy or not.

The claims used as evidence and attestation for DNS server is discussed in
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04.

Cheers,
-Tiru

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2020 08:23:29 -0400

> Don't care. These are not high-security networks.

Haven't you heard? Home networks are the new office networks.

Joe

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 30 Jul 2020 14:51:22 +0200 (CEST)

>     Il 29/07/2020 18:50 Tommy Jensen <jensen.thomas=[email-masked]> ha scritto:
>      
>      
>     Hey Andrew,
>      
I'm not Andrew nor a lawyer, but for what regards myself, the GDPR concerns about the adaptive DNS model are that it creates a way for an extremely high number of third parties to ask the browser for DNS data that they would not currently get, countering the principles of privacy by design and data minimization that are mandated by the GDPR whenever data processing activities are conceived.

I understand the point that these parties would generally be the ones that would later be contacted through an application-layer protocol to get the actual service, but it still need to be assessed whether the DNS query can be considered as part of the actual service, whether it does not disclose additional information, and so on; and more importantly, I see no guarantees that this mechanism cannot rather be used to bring additional parties into the loop, by designating them as DNS providers, and broaden the set of entities that get the user's information.

It's true that the burden of finding good, legal and privacy-protecting policies for using the specs could be left to implementations, but this could be said of pretty much anything. Even the dreaded "eTLS" architecture could have been implemented legally and positively under an appropriate choice of policies, yet the IETF rightfully decided to reject it, as the architecture itself was too prone to privacy damage. In fact, RFC 6973 gives data minimization and user control as guidelines for protocol design, and the adaptive DNS model IMHO counters both of those principles.

--

---

From: "Chris Box (BT)" <[email-masked]>
Date: Thu, 30 Jul 2020 14:00:23 +0100

> https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04.
Thanks Tiru. I hadn't looked into RATS, and I have to confess that crypto
is not my domain so I look to others to do that and tell me what it all
means. But on the surface it looks positive.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Jul 2020 09:15:25 -0400

On Jul 30, 2020, at 12:21 AM, tirumal reddy <[email-masked]> wrote:
> On Thu, 30 Jul 2020 at 04:09, Rob Sayre <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Jul 29, 2020 at 8:52 PM tirumal reddy <[email-masked] <mailto:[email-masked]>> wrote:
> My point is parental control is not restricted to Apple devices and your proposal of device profile is not solving the problem for home network deployments.

I get the sense that you’re suggesting that somehow the network should be offering to the device that it install a device profile. This can’t work because it’s not safe to trust the network. There has to be an explicit trust decision. I don’t know about other ecosystems, but on the iPhone you have to explicitly choose to install a profile—it doesn’t just happen when you join a network. I don’t think there’s a way for the IETF to standardize this process—it’s going to be specific to the operating system or ecosystem. We /could/ standardize what the profile looks like, I guess.

---

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 30 Jul 2020 15:28:57 +0200

tirumal reddy wrote in
 <[email-masked]>:
 |Hi Chris,
 |
 |Good points, please see inline
 |
 |On Thu, 30 Jul 2020 at 06:00, Chris Box (BT) <[email-masked]>
 |wrote:
 |
 |> Rob you appear to be saying you don’t need such features to secure a home
 |> network, but I would certainly appreciate having Tiru’s (a) to (e) \
 |> deployed
 |> in my house. I don’t want the smart TV equipped with microphone and \
 |> webcam
 |> to be remotely compromised, nor any other device. Without such
 |> network-level control, enabled by standards, my only defence is to
 |> physically unplug the TV from the network when not in use.
 |>
 |
 |> Following Eva’s talk in HRPC, I’ll put myself in the shoes of a dissident
 |> in a hostile regime. In such a case I would feel even greater need \
 |> for such
 |> security. Of course I would choose my security supplier carefully, \
 |> and not
 |> one aligned to the regime. I then need one or two devices that route
 |> through Tor.
 |>
 |> I fully agree the challenge is to distinguish legitimate network signals
 |> from those of an attacker. Robustly identifying who they came from is
 |> non-trivial, but hopefully not impossible?
 |>
 |
 |Yes, identifying the trustworthiness of the peer is discussed in RATS WG
 |(see https://datatracker.ietf.org/wg/rats/about/). Remote attestation
 |procedures (RATS) enable relying parties to establish a level of confidence
 |in the trustworthiness of remote system components through the creation of
 |attestation evidence by remote system components and a processing
 |chain towards the relying party. A relying party can then decide whether
 |to consider a remote system component trustworthy or not.
 |
 |The claims used as evidence and attestation for DNS server is discussed in
 |https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04.

I personally do not get what yet another line of authorities
transported via JSON encoded structures fetched via another DNS
record that just exposes that JSON structure gives the world anew.

Indirection may make everything possible, but, i mean, to me the
key point of RFC 8572 for example is the

  3.3 Ownership Voucher
  [this] artifact is used to securely identify a device's owner,
  as it is known to the manufacturer.  The ownership voucher is
  signed by the device's manufacturer.

_If_ i can find my way home i can securely update myself, where
securely means manufacturer here.  Great that standard CMS is
used.

  Even if DNSSEC [RFC6698] is used to authenticate the various DNS
  resource records [.] the device cannot be sure that the domain
  returned to it, e.g., from a DHCP server, belongs to its
  rightful owner.

It then refers back to RFC 6763, DNS-based service discovery.
Which has really nice, easy to parse content, and does not use
JSON only to represent key/value pairs.  (Why not a fixed CBOR
thing instead, they are talking maps at the moment, for example.
And can easily be converted back and forth to JSON while still
being parsed directly, as it is binary.)  What is so wrong with
this service discovery thing, i think it could very well serve
additional things.  But especially so if another registry is
introduced for the concept.  RFC 8572 also says

  Using a DHCP server may be a compelling option for deployments
  having existing DHCP infrastructure, as it enables a touchless
  bootstrapping option that does not entail utilizing an
  Internet-based resource hosted by a third party.

  A DHCP server is an untrusted source of bootstrapping data.
  Thus, the information stored on the DHCP server either MUST be
  signed or MUST be information that can be processed
  provisionally (e.g., unsigned redirect information).

I do not know (people can agree here), but if that could improve.
Also being x-rayed yesterday (untreated bike accident last
November) my pictures are now at healthdataspace.org even without
me agreeing with that, they have a German data security seal of
approval, but then it is just a QR-code and/or an access code
(alphanumeric and length of 10 or 12, iirc).

It is not an option for a light bulb, but that thing surely
belongs behind a household router, and easy usable routers with
why not ample-style use cases would be great, imho.  With a short
fingerprint printed on a device that shows up on that router, just
like for Bluetooth pairing.  I could imagine people could get used
to that.  (Especially with some kind of those terrible apps on
their smart phones which are linked to the "router" of the
household, then, so they get informed of that event.  I think DHCP
even allows ident strings to be emitted from DHCP client to
server.)

Sorry, i do not seem to understand.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 30 Jul 2020 15:34:06 +0200

Steffen Nurpmeso wrote in
 <[email-masked]>:
 ...
 |It is not an option for a light bulb, but that thing surely
 |belongs behind a household router, and easy usable routers with
 |why not ample-style use cases would be great, imho.  With a short
 |fingerprint printed on a device that shows up on that router, just

Of a standard CMS / X509 client certificate that is to say.

--steffen
|

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 30 Jul 2020 06:49:22 -0700

Hi Andrew,

First, I want to separate out the mechanism for discovery from the usage and interaction with user preferences. The focus of the draft currently being proposed is to define the mechanism to inform client devices about designated resolvers. The client may choose to have a specific list of resolvers it allows designation to. And, if a user has chosen a specific DNS provider to trust for all traffic, or have a VPN, that ought to take precedence over a more dynamic system with multiple resolvers.

I think it’s also worth digging in on the idea that “personal data is being shared and processed widely”. The goal of using a designated resolver is to *limit* the amount of connection metadata that is being shared to various parties, and to reduce the data sharing to an entity that is already involved in helping clients established connections (both by being an entity that can run the authoritative DNS and by running the actual origin server endpoints). It is also important to note that there is no client identifier sent other than the IP address (assuming that a client connects directly to the DoH server and not with a proxy, in which case even IP addresses are not visible).

Thanks,
Tommy Pauly

> On Jul 29, 2020, at 11:45 PM, Andrew Campling <[email-masked]> wrote:
> 
> Tommy
> Picking up the thread and also answering your earlier question about GDPR (noting that I am also not a lawyer!), I think that it would be highly problematic to have adaptive DNS on by default.  To expand, a user has expressed a preference for a DNS service, either through the acceptance of the ISP’s service in signing their contract or by subsequently, Google or Cloudflare or Quad9 etc deliberately.  Adaptive DNS *appears* (I may have misunderstood) to make on-the-fly decisions about the DNS resolver based on recommendations received, which in turn appears to be at odds with the choice made by the user if it is on by default.   
>  
> This could of course be dealt with by gaining user consent first, however it does seem that personal data is being shared and processed widely without any indication of the privacy policies in operation by the recipients.  (I could of course suggest a suitable, GDPR-compliant privacy policy but that’s off-topic for this group. :-) )
>  
> Andrew
>  
>   Native gRPC support: https://aka.ms/grpcblogpost <https://aka.ms/grpcblogpost> 
>   DNS over HTTPS: https://aka.ms/dohblogpost <https://aka.ms/dohblogpost> 
>  
> From: Chris Box (BT) <[email-masked] <mailto:[email-masked]>>
> To: Tommy Jensen <[email-masked] <mailto:[email-masked]>>
> Cc: Andrew Campling <[email-masked] <mailto:[email-masked]>>; ADD Mailing list <[email-masked] <mailto:[email-masked]>>
> On Wed, 29 Jul 2020 at 17:50, Tommy Jensen <Jensen.Thomas=[email-masked]..org <mailto:[email-masked]>> wrote:

---

From: tirumal reddy <[email-masked]>
Date: Thu, 30 Jul 2020 13:57:55 +0000

On Thu, 30 Jul 2020 at 13:15, Ted Lemon <[email-masked]> wrote:

> I get the sense that you’re suggesting that somehow the network should be
> offering to the device that it install a device profile. This can’t work
> because it’s not safe to trust the network. There has to be an explicit
> trust decision. I don’t know about other ecosystems, but on the iPhone you
> have to explicitly choose to install a profile—it doesn’t just happen when
> you join a network.
>

Yes, the on-boarding process of BYOD in Enterprise networks allows the user
to authenticate to the directory service and vice-versa, and then the
configuration profile is installed on the endpoint, see
https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/OTASecurity.html
for
more details.

> I don’t think there’s a way for the IETF to standardize this process—it’s
> going to be specific to the operating system or ecosystem.
>

Agreed, my question is how do we get this delivery mechanism to work in a
home network ?

> We /could/ standardize what the profile looks like, I guess.
>

Yes, it will help solve the problem in certain scenarios like Enterprise
networks for Apple devices. I have not looked into OTA for other operating
systems.

Cheers,
-Tiru

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Jul 2020 10:08:11 -0400

On Jul 30, 2020, at 9:57 AM, tirumal reddy <[email-masked]> wrote:
> Yes, the on-boarding process of BYOD in Enterprise networks allows the user to authenticate to the directory service and vice-versa, and then the configuration profile is installed on the endpoint, see https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/OTASecurity.html <https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/OTASecurity.html> for more details.
>  
> I don’t think there’s a way for the IETF to standardize this process—it’s going to be specific to the operating system or ecosystem.
> 
> Agreed, my question is how do we get this delivery mechanism to work in a home network ?

As I said, it’s going to be specific to the operating system, so we can’t do it—it’s not our job. That doesn’t mean it can’t be done. The Apple solution is an example of it being done, although a bit more all-singing, all-dancing than we are talking about here.
 
> Yes, it will help solve the problem in certain scenarios like Enterprise networks for Apple devices. I have not looked into OTA for other operating systems.

If the device ecosystem provides some sort of parental control model, then this should work for any user of such a device, not just enterprise users. The DoH server in this case would be the solution provider’s DoH server, not the local network DoH server.

---

From: tirumal reddy <[email-masked]>
Date: Fri, 31 Jul 2020 05:46:05 +0000

On Thu, 30 Jul 2020 at 14:08, Ted Lemon <[email-masked]> wrote:

> Yes, the on-boarding process of BYOD in Enterprise networks allows the
> user to authenticate to the directory service and vice-versa, and then the
> https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/OTASecurity.html for
> more details.
>
>
> As I said, it’s going to be specific to the operating system, so we can’t
> do it—it’s not our job. That doesn’t mean it can’t be done. The Apple
> solution is an example of it being done, although a bit more all-singing,
> all-dancing than we are talking about here.
>

The problem is not with operating systems but the procedure to
on-board/bootstrap devices, it is different in a Home network compared to
an Enterprise network.

The bootstrapping process in
https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/OTASecurity.html
is assuming the endpoint has unique credentials assigned by the network
admin to authenticate to the network and vice-versa to install the profile.
The network admin has also provided the enroll URL to the user and requires
local CA installation. The delivery process uses SCEP and does not seem to
support EST.

If we complicate the on-boarding in home deployments and increase human
interaction, I am afraid it will not fly.

> If the device ecosystem provides some sort of parental control model, then
> this should work for any user of such a device, not just enterprise users.
> The DoH server in this case would be the solution provider’s DoH server,
> not the local network DoH server.
>

Two types of parent controls are widely deployed today (1) DNS firewall in
the home router or ISP filtering domains (2) setting parental control on
the device itself.

What solution provider are you referring to ?

-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Fri, 31 Jul 2020 06:20:46 +0000

> record that just exposes that JSON structure gives the world anew.

RATS allows the attestation to be represented in JSON or CBOR (see
https://tools.ietf.org/html/draft-ietf-rats-eat-03#section-1.1).  The PAT
object is retrieved using RESINFO RRtype (
https://tools.ietf.org/html/draft-pp-add-resinfo-01) and it uses JSON to
return the resolver information.

> securely means manufacturer here.  Great that standard CMS is

https://tools.ietf.org/html/rfc8572 is specific to zero-touch provisioning
of networking devices and IoT devices in Enterprise networks. The owner
certificate can be used to validate the PAT signature (see the last
paragraph
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04#section-10
).

> even allows ident strings to be emitted from DHCP client to

There are several mechanisms to securely bootstrap IoT devices, you may
want to look into the recently adopted draft
https://tools.ietf.org/html/draft-sarikaya-t2trg-sbootstrapping-08 by T2TRG
and
within the scope of IETF is BRSKI and SZTP.

Cheers,
-Tiru

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 31 Jul 2020 08:13:11 +0000

Hi Steffen,

In-line.

> even allows ident strings to be emitted from DHCP client to

You might find this useful: 
https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01. Sure it uses 
EAP, but it is about time we move to better security protocols (rather 
than relying on network-wide shared secrets). EAP naturally also allows 
you to run the server in the home router or in the cloud and do all 
sorts of federation/roaming (such as eduroam).

I would also add that the most light bulbs don't speak directly to the 
home router and often have their own gateway (or what Philips calls a 
bridge) to translate zigbee to Wi-Fi/ethernet etc.

--Mohit

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 31 Jul 2020 08:13:35 +0000

Hi Tiru,

https://tools.ietf.org/html/draft-sarikaya-t2trg-sbootstrapping-08 isn't adopted by T2TRG yet. Of course (as an author) it would be nice. It probably requires a couple of iterations and reviews before it can be considered for adoption.

I would also add EAP-NOOB to the list (https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01).

--Mohit

On 7/31/20 9:20 AM, tirumal reddy wrote:
On Thu, 30 Jul 2020 at 13:28, Steffen Nurpmeso <[email-masked]<mailto:[email-masked]>> wrote:
tirumal reddy wrote in
 <[email-masked]<mailto:[email-masked]>>:
 |Hi Chris,
 |
 |On Thu, 30 Jul 2020 at 06:00, Chris Box (BT) <[email-masked]<mailto:[email-masked]>>

RATS allows the attestation to be represented in JSON or CBOR (see https://tools.ietf.org/html/draft-ietf-rats-eat-03#section-1.1).  The PAT object is retrieved using RESINFO RRtype (https://tools.ietf.org/html/draft-pp-add-resinfo-01) and it uses JSON to return the resolver information.

  3.3 Ownership Voucher

https://tools.ietf.org/html/rfc8572 is specific to zero-touch provisioning of networking devices and IoT devices in Enterprise networks. The owner certificate can be used to validate the PAT signature (see the last paragraph https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-04#section-10).

November) my pictures are now at healthdataspace.org<http://healthdataspace.org> even without

There are several mechanisms to securely bootstrap IoT devices, you may want to look into the recently adopted draft https://tools.ietf.org/html/draft-sarikaya-t2trg-sbootstrapping-08 by T2TRG and
within the scope of IETF is BRSKI and SZTP.

Cheers,
-Tiru

--steffen
|

---

From: tirumal reddy <[email-masked]>
Date: Fri, 31 Jul 2020 08:50:55 +0000

> sorts of federation/roaming (such as eduroam).

+1. EAP will solve several attacks like Evil twin and weaknesses in
WPA2/WPA3. It also helps to uniquely identify devices without having to
rely on MAC addresses and the network security service can enforce device
isolation to quarantine infected devices (and can deal with MAC spoofing).

-Tiru

---

From: Steffen Nurpmeso <[email-masked]>
Date: Fri, 31 Jul 2020 14:44:02 +0200

Mohit Sethi M wrote in
 <[email-masked]>:
 |Hi Steffen,
 |
 |In-line.

Well.

 |You might find this useful: 
 |https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01. Sure it uses 

No, not me, sorry.

 |I would also add that the most light bulbs don't speak directly to the 
 |home router and often have their own gateway (or what Philips calls a 
 |bridge) to translate zigbee to Wi-Fi/ethernet etc.

I was reiterating an example that had been used in the thread.
I could have used refrigerator instead.  But i did not.

--steffen
|

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 31 Jul 2020 09:41:26 -0400

Hi Vittorio,

Fortunately, eTLS was shifted to ETSI TC CYBER by the industry, 
significantly improved, adopted as ETS, rolled out with running code by 
providers in the marketplace, and now being widely used worldwide by 
enterprise network providers.  The persistent URI of the current version 
is 
https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.03.01_60/ts_10352303v010301p.pdf

The marketplace ultimately prevails in deciding what capabilities are 
needed and "routes around" difficult venues. :-)

--tony

On 30-Jul-20 8:51 AM, Vittorio Bertola wrote:
>> Il 29/07/2020 18:50 Tommy Jensen 
>> <jensen.thomas=[email-masked]> ha scritto:
>> Hey Andrew,
>> Can you be specific about your GDPR concerns? Each time I press on 
>> what parts of the proposals run afoul of GDPR, here or in other DNS 
>> bodies, I'm told "talk to your lawyer" which, to be fair, is a valid 
>> answer. However, if there are not specific technical concerns that 
>> can be shared on list, I don't think we should block standard design 
>> on the vague legal risk that _might_ exist. Let's be specific about 
>> the GDPR concerns.
> I'm not Andrew nor a lawyer, but for what regards myself, the GDPR 
> concerns about the adaptive DNS model are that it creates a way for an 
> extremely high number of third parties to ask the browser for DNS data 
> that they would not currently get, countering the principles of 
> privacy by design and data minimization that are mandated by the GDPR 
> whenever data processing activities are conceived.
> I understand the point that these parties would generally be the ones 
> that would later be contacted through an application-layer protocol to 
> get the actual service, but it still need to be assessed whether the 
> DNS query can be considered as part of the actual service, whether it 
> does not disclose additional information, and so on; and more 
> importantly, I see no guarantees that this mechanism cannot rather be 
> used to bring additional parties into the loop, by designating them as 
> DNS providers, and broaden the set of entities that get the user's 
> information.
> It's true that the burden of finding good, legal and 
> privacy-protecting policies for using the specs could be left to 
> implementations, but this could be said of pretty much anything. Even 
> the dreaded "eTLS" architecture could have been implemented legally 
> and positively under an appropriate choice of policies, yet the IETF 
> rightfully decided to reject it, as the architecture itself was too 
> prone to privacy damage. In fact, RFC 6973 gives data minimization and 
> user control as guidelines for protocol design, and the adaptive DNS 
> model IMHO counters both of those principles.
>
> -- 
>
> [email-masked]  <mailto:[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Jul 2020 07:04:40 -0700

On Fri, Jul 31, 2020 at 6:41 AM Tony Rutkowski <[email-masked]>
wrote:

> enterprise network providers.
>
Interesting. Can you expand on this? Which vendors provide ETS
implementations? Are there any open source ones?

-Ekr

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 31 Jul 2020 11:11:07 -0400

Hi Eric,

Might I suggest you join the ETSI TC CYBER MSP group and you can find 
out - even participate in the hackathons!

cheers,
tony

On 31-Jul-20 10:04 AM, Eric Rescorla wrote:
>
>
> On Fri, Jul 31, 2020 at 6:41 AM Tony Rutkowski 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Vittorio,
>
>     significantly improved, adopted as ETS, rolled out with running
>     code by providers in the marketplace, and now being widely used
>     worldwide by enterprise network providers.
>