Subject: [Add] A proposed charter for ABCD

From: Ben Schwartz <[email-masked]>
Date: Fri, 20 Dec 2019 10:20:17 -0500

Hello ADD list,

Based on the feedback from the ABCD BoF at IETF 106, and with additional
input from chairs and area directors from relevant working groups, the ABCD
BoF chairs have drafted the following updated charter for a working group.
Please review it and share your perspective.

Tommy Pauly has recently posted a charter text proposal that considers
closely related issues. This is not a competition, so please avoid “voting”
for one proposed text over the other.  The text of any final charter will
be written by the IESG.  To help them judge whether a working group should
be formed, and how it should be chartered, the most productive input would
be to know which elements of each text you find valuable (if any), and
which you would like to see changed in any final charter.

-----------------------------------

Proposed charter text:

This working group will focus on DNS client side topics, particularly
discovery and selection of resolvers. This complements existing DNS-related
working groups, which are responsible for improvements to the DNS protocol
itself, and for operational questions that are principally of interest to
DNS server operators.

The working group is chartered to develop an extensible protocol for a DNS
client to learn detailed information about a resolver, based on
draft-ietf-dnsop-resolver-information, which will be transferred from
dnsop.  Relying on this new protocol where appropriate, the working group
should produce standards-track, informational, or experimental documents
that provide the following items, using the drafts in brackets as input
(with no obligation to adopt them):
 * methods for a recursive resolver to advertise support for an alternative
transport protocol [draft-sah-resinfo-doh],
 * methods for a recursive resolver to indicate that it will sometimes
return DNS results that are different from the global DNS
[draft-grover-add-policy-detection],
 * methods for improving user privacy by avoiding DNS queries that leak
information or directing them to a server that will have this information
anyway [draft-pauly-dprive-adaptive-dns-privacy], and
 * a format for describing the client’s DNS configuration, suitable for
diagnostics and debugging.

Where possible, any mechanisms that specify exchange of information between
clients and resolvers should provide the security properties expected of
IETF protocols, e.g., confidentiality protection, integrity protection, and
authentication with strong work factor.  Each specification must clearly
indicate under what circumstances and assumptions these properties are or
are not provided.

This working group will coordinate and share WGLC announcements with the
following working groups: dnsop, capport, dprive, dhc, and homenet. The
working group will also coordinate with the Security Area, and will be
assigned a security advisor.

P.S. One note regarding this proposal: the chairs of the doh working group
expect that doh would be closed if a new working group were chartered in
this manner or similar.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 20 Dec 2019 10:44:07 -0500

I believe a clarification is needed regarding the advertising of resolver capabilities. That is discovery of local resolver properties versus global resolver properties. These methods might need to be completely different (eg DHCP vs something else).

It would be good to clarify both are in scope.

Paul

Sent from my iPhone

> On Dec 20, 2019, at 10:20, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> Hello ADD list,
> 
> Based on the feedback from the ABCD BoF at IETF 106, and with additional input from chairs and area directors from relevant working groups, the ABCD BoF chairs have drafted the following updated charter for a working group.  Please review it and share your perspective.
> 
> Tommy Pauly has recently posted a charter text proposal that considers closely related issues. This is not a competition, so please avoid “voting” for one proposed text over the other.  The text of any final charter will be written by the IESG.  To help them judge whether a working group should be formed, and how it should be chartered, the most productive input would be to know which elements of each text you find valuable (if any), and which you would like to see changed in any final charter.
> 
> This working group will focus on DNS client side topics, particularly discovery and selection of resolvers. This complements existing DNS-related working groups, which are responsible for improvements to the DNS protocol itself, and for operational questions that are principally of interest to DNS server operators.
> 
> The working group is chartered to develop an extensible protocol for a DNS client to learn detailed information about a resolver, based on draft-ietf-dnsop-resolver-information, which will be transferred from dnsop.  Relying on this new protocol where appropriate, the working group should produce standards-track, informational, or experimental documents that provide the following items, using the drafts in brackets as input (with no obligation to adopt them):
>  * methods for a recursive resolver to advertise support for an alternative transport protocol [draft-sah-resinfo-doh],
>  * methods for a recursive resolver to indicate that it will sometimes return DNS results that are different from the global DNS [draft-grover-add-policy-detection],
>  * methods for improving user privacy by avoiding DNS queries that leak information or directing them to a server that will have this information anyway [draft-pauly-dprive-adaptive-dns-privacy], and
>  * a format for describing the client’s DNS configuration, suitable for diagnostics and debugging.
> 
> Where possible, any mechanisms that specify exchange of information between clients and resolvers should provide the security properties expected of IETF protocols, e.g., confidentiality protection, integrity protection, and authentication with strong work factor.  Each specification must clearly indicate under what circumstances and assumptions these properties are or are not provided.
> 
> This working group will coordinate and share WGLC announcements with the following working groups: dnsop, capport, dprive, dhc, and homenet. The working group will also coordinate with the Security Area, and will be assigned a security advisor.
> 
> P.S. One note regarding this proposal: the chairs of the doh working group expect that doh would be closed if a new working group were chartered in this manner or similar.
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 20 Dec 2019 10:52:54 -0500

On Fri, Dec 20, 2019 at 10:44 AM Paul Wouters <[email-masked]> wrote:

> I believe a clarification is needed regarding the advertising of resolver
> capabilities. That is discovery of local resolver properties versus global
> resolver properties.

Could you describe the distinction you're thinking about?  What is a "local
property" of a resolver?  Or do you mean to distinguish "local resolvers"
from "global resolvers"?

> These methods might need to be completely different (eg DHCP vs something
> else).
>
> > The working group is chartered to develop an extensible protocol for a
> DNS client to learn detailed information about a resolver, based on
> >  * methods for a recursive resolver to advertise support for an
> alternative transport protocol [draft-sah-resinfo-doh],
> > Where possible, any mechanisms that specify exchange of information
> between clients and resolvers should provide the security properties
> expected of IETF protocols, e.g., confidentiality protection, integrity
> protection, and authentication with strong work factor.  Each specification
> must clearly indicate under what circumstances and assumptions these
> properties are or are not provided.
> >
> > P.S. One note regarding this proposal: the chairs of the doh working
> group expect that doh would be closed if a new working group were chartered
> in this manner or similar.
> > --
> > Add mailing list
> > [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Fri, 20 Dec 2019 11:08:18 -0500

> On Dec 20, 2019, at 10:52, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
>> I believe a clarification is needed regarding the advertising of resolver capabilities. That is discovery of local resolver properties versus global resolver properties.
> 
> Could you describe the distinction you're thinking about?  What is a "local property" of a resolver?  Or do you mean to distinguish "local resolvers" from "global resolvers"?

The advertising of properties most likely are different for local (DHCP) and global (DNS?) resolvers. I want to avoid the WG declaring one of these out of scope.

Paul

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Dec 2019 11:15:10 -0500

> The text of any final charter will be written by the IESG.  To help them judge whether a working
> group should be formed, and how it should be chartered, the most productive input would be to
> know which elements of each text you find valuable (if any), and which you would like to see
> changed in any final charter.

The second sentence is absolutely correct, but to clarify on the first:
The text of any final charter will be proposed by the community, and
will be approved by the IESG.  We'll do tweaking of wording and such,
but the community has to decide what you want to work on.

Barry, ART AD

---

From: Rob Sayre <[email-masked]>
Date: Fri, 20 Dec 2019 13:15:57 -0800

It seems like the key difference between this proposal and Tommy Pauly's is
the "Where possible," at the start of the paragraph detailing security
properties. However, last I checked, these properties are not optional in
IETF protocols. Several of the proposals above look like they'll hinge on
this turn of phrase, so I don't think it's wise to punt on the
justification here. It should probably be in the charter with alongside
each work item, each of which should be more concrete. In some cases, it's
difficult to argue that these drafts make things worse, but those that
enable a downgrade from encrypted traffic are difficult to distinguish from
attacks.

In secure deployments, the network operator will be able to bootstrap DNS
(via enterprise policy, parental control software, etc). For situations
where the device is not controlled by the network, methods of
authenticating the DNS server seem called for. Since the client
(application or OS) needs to rely on the DNS for software updates to keep
it secure, it doesn't seem like Web PKI provides adequate guarantees.
Something like OIDC seems more appropriate for large-scale deployments,
where managing each client is difficult to do (example: authenticate your
ISP with OS or Browser Single Sign-In).

One possible work item for the group might be to document the security of a
variety of DNS bootstrapping options, starting from the bottom: unencrypted
DNS learned via DHCP.

thanks,
Rob

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 23 Dec 2019 15:30:07 +0100 (CET)

Thanks for putting this together, and see comments below.

Il 20/12/2019 16:20 Ben Schwartz <bemasc=[email-masked]> ha scritto:

Proposed charter text:

The working group is chartered to develop an extensible protocol for a DNS client to learn detailed information about a resolver, based on draft-ietf-dnsop-resolver-information, which will be transferred from dnsop.

I think that one actual problem that many here would like to solve is: for decades we have been discovering and using the local network-provided resolver as a default, we would like to continue doing that but with an encrypted local resolver, how do we do that? This draft charter seems to assume that the client will discover the unencrypted local resolver through the currently existing protocols, leaving this phase out of scope, and then will use a new method, to be developed and in scope for this group, to find out the encrypted local resolver that matches the unencrypted one. But are we already sure that this is the best solution for the problem, rather than developing something new that does both things at the same time? Otherwise, the mission above should also include, at least as an option, the discovery of locally available encrypted resolvers.

Relying on this new protocol where appropriate, the working group should produce standards-track, informational, or experimental documents that provide the following items, using the drafts in brackets as input (with no obligation to adopt them): * methods for a recursive resolver to advertise support for an alternative transport protocol [draft-sah-resinfo-doh],

Building on what I said above, I will point out that conceptually users are not interested in a resolver's policy, but rather in the local network's policy, i.e. conditions, restrictions and safeguards to Internet access effected by the network's owner via DNS. So it is useless to have the capability for a resolver to indicate policy, if there is not also the capability for a client to discover that that resolver exists and is able to provide information on the local network's policy.

* methods for improving user privacy by avoiding DNS queries that leak information or directing them to a server that will have this information anyway [draft-pauly-dprive-adaptive-dns-privacy],

I am still not convinced that the concept in that draft "improves user privacy". Can we please avoid giving that for granted?

Also, more generally, the idea of using many resolvers at once, rather than a single one, opens several cans of worms in policy and legal terms, and possibly even in terms of "security & stability" (in the ICANN sense). Perhaps the IETF should stop working on new technical developments just because it can, and assess the non-technical implications of these new developments before working on them.

and * a format for describing the client’s DNS configuration, suitable for diagnostics and debugging.

This is not only true of security, but also of privacy - some mechanisms could provide more or less of it depending on the assumptions and on the privacy threat model, and this should also be discussed.

There should also be work on documenting the existing use cases and services that consumer DNS resolvers provide, so that one could see whether the assumptions above are met in real world situations or not.

--

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

---

From: "Smith, Kevin, Vodafone Group" <[email-masked]>
Date: Mon, 23 Dec 2019 15:55:04 +0000

Thanks for sharing the draft, Ben.

> Where possible, any mechanisms that specify exchange of information between clients and resolvers should provide the security properties expected of IETF protocols, e.g., confidentiality protection, integrity protection, and authentication with strong work factor.

The preceding text explicitly states 'recursive resolvers' several times, but 'recursive' is not explicitly stated here. Does this  statement therefore encompass all resolvers in a chain, and the security/ privacy uplift that implies?

Regarding 'where possible': I'm struggling to think of a case where it wouldn't be possible, only a case where there may be a side-effect: e.g. a constrained-power IOT device incurring additional radio transmissions and crypto cycles.

> Each specification must clearly indicate under what circumstances and assumptions these properties are or are not provided.

And so should implementations (as part of 'resolver information') at the point of discovery.

All best,
Kevin
Vodafone R&D

From: Add <[email-masked]> On Behalf Of Ben Schwartz
Sent: 20 December 2019 15:20
To: ADD Mailing list <[email-masked]>
Subject: [Add] A proposed charter for ABCD

Hello ADD list,

Tommy Pauly has recently posted a charter text proposal that considers closely related issues. This is not a competition, so please avoid "voting" for one proposed text over the other.  The text of any final charter will be written by the IESG.  To help them judge whether a working group should be formed, and how it should be chartered, the most productive input would be to know which elements of each text you find valuable (if any), and which you would like to see changed in any final charter.

Proposed charter text:

 * a format for describing the client's DNS configuration, suitable for diagnostics and debugging.

C2 General

---

From: Eric Orth <[email-masked]>
Date: Mon, 23 Dec 2019 12:39:02 -0500

On Mon, Dec 23, 2019 at 9:30 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> anyway [draft-pauly-dprive-adaptive-dns-privacy],
>
> I am still not convinced that the concept in that draft "improves user
> privacy". Can we please avoid giving that for granted?
>

While I believe you and I share some concerns regarding the Adaptive DNS
draft, I don't think the proposed charter does give that for granted.  The
proposal states that "methods for improving user privacy" should be part of
the WG.  I agree that that general privacy improvement topic should
definitely be under the scope of the WG.  The proposal also states that the
Adaptive DNS draft should be input to the discussion with no obligation to
adopt.  I also agree with that language, as I think the proposed WG would
be the ideal place to discuss the draft, including discussions of how well
or not the draft fits into the privacy goals of the WG.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 24 Dec 2019 10:02:49 +0100 (CET)

Il 23/12/2019 18:39 Eric Orth <ericorth=[email-masked]> ha scritto:

While I believe you and I share some concerns regarding the Adaptive DNS draft, I don't think the proposed charter does give that for granted.  The proposal states that "methods for improving user privacy" should be part of the WG.  I agree that that general privacy improvement topic should definitely be under the scope of the WG.  The proposal also states that the Adaptive DNS draft should be input to the discussion with no obligation to adopt.  I also agree with that language, as I think the proposed WG would be the ideal place to discuss the draft, including discussions of how well or not the draft fits into the privacy goals of the WG.

It's entirely fine to have the topic of better privacy in the charter, but the specification "directing them to a server that will have this information anyway" seemed very specific to the draft, preempting the discussion on its adoption. Perhaps we can just stop at "methods for improving user privacy".

--

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Dec 2019 14:39:07 -0500

Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
    > I think that one actual problem that many here would like to solve is:
    > for decades we have been discovering and using the local
    > network-provided resolver as a default, we would like to continue doing
    > that but with an encrypted local resolver, how do we do that?

While I'm with you, I'm not sure that this is what others want.

    > This
    > draft charter seems to assume that the client will discover the
    > unencrypted local resolver through the currently existing protocols,
    > leaving this phase out of scope, and then will use a new method, to be
    > developed and in scope for this group, to find out the encrypted local
    > resolver that matches the unencrypted one. But are we already sure that
    > this is the best solution for the problem, rather than developing
    > something new that does both things at the same time? Otherwise, the
    > mission above should also include, at least as an option, the discovery
    > of locally available encrypted resolvers.

I.e. why do insecure DHCP followed by some mechanism X to establish trust, when
we could just do secure discovery mechanism X' ?

    > Building on what I said above, I will point out that conceptually users
    > are not interested in a resolver's policy, but rather in the local
    > network's policy, i.e. conditions, restrictions and safeguards to
    > Internet access effected by the network's owner via DNS.

Have you seen draft-reddy-dprive-dprive-privacy-policy-00 and
draft-reddy-dprive-bootstrap-dns-server?

    > Also, more generally, the idea of using many resolvers at once, rather
    > than a single one, opens several cans of worms in policy and legal
    > terms, and possibly even in terms of "security & stability" (in the
    > ICANN sense)..  Perhaps the IETF should stop working on new technical
    > developments just because it can, and assess the non-technical
    > implications of these new developments before working on them.

If only we were lawyers, and legal code was deterministic.

I think that a failing in the current charter is that we haven't
distinguished the target client user for this process:

Is it:
1) browsers with users attached?  (Are they BYOD?)
2) Operating systems with browsers attached? (Are they BYOD?)
3) Corporate desktops with group policy in control?
4) IoT and other unattended systems (printers, routers) which are
   under the same authority as the network?
5) people with BYOD at random coffee shops.

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 24 Dec 2019 10:09:51 -1000

> On Dec 24, 2019, at 9:39 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

You are assuming that people obviously want to continue doing what they are doing but only with an encrypted access to a local server. Rather than assuming that, it might be better to unpack the tradeoff behind that particular solution, and explain in which circumstances they make sense.

Personally I believe there is a difference between retrieving  an A or AAAA record and retrieving an ESNI record. Resolving the first one locally may well be convenient. Resolving the ESNI locally leads to a very clear privacy exposure.

-- Christian Huitema

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Dec 2019 15:28:16 -0500

Christian Huitema <[email-masked]> wrote:
    >>> I think that one actual problem that many here would like to solve
    >>> is: for decades we have been discovering and using the local
    >>> network-provided resolver as a default, we would like to continue
    >>> doing that but with an encrypted local resolver, how do we do that?
    >>

    > You are assuming that people obviously want to continue doing what they
    > are doing but only with an encrypted access to a local server. Rather
    > than assuming that, it might be better to unpack the tradeoff behind
    > that particular solution, and explain in which circumstances they make
    > sense.

    > Personally I believe there is a difference between retrieving an A or
    > AAAA record and retrieving an ESNI record. Resolving the first one
    > locally may well be convenient. Resolving the ESNI locally leads to a
    > very clear privacy exposure.

I'm confused by the word "locally" here.
But, maybe that's part of the tussle here.

I'm not sure if you mean disclosing the query to local listeners (because it
is not encrypted) leads to a privacy exposure.

or if you mean disclosing the query to a local resolver (possibly via
encrypted session layer), to which to there is known privacy statement,
results in a privacy exposure.

Again, I don't who the client is, and who controls the device being used, and
who the user is (or if there is a user).

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Dec 2019 16:29:57 -0500

> I'm confused by the word "locally" here.  But, maybe that's part of the
    > tussle here.

    > I'm not sure if you mean disclosing the query to local listeners
    > (because it is not encrypted) leads to a privacy exposure.

    > results in a privacy exposure.

typo,  I meant to write: "to which there is not a known privacy statement"

---

From: Christian Huitema <[email-masked]>
Date: Tue, 24 Dec 2019 12:09:55 -1000

>     > I'm confused by the word "locally" here.  But, maybe that's part of the

I was using that as a shortcut for "the recursive resolver that the
network/DHCP server indicates".

>     > (because it is not encrypted) leads to a privacy exposure.

I am assuming that local listeners who can see the DNS queries can also
see the unencrypted parts of the data traffic, such as IPv4/IPv6
headers, and unencrypted SNI value. Since they see that already, they
know the content of the A/AAAA queries and responses. The local resolver
would not gain any information that could not be obtained by looking
directly at traffic.

OTOH, the local listeners have no idea of what the content of the ESNI
is. Disclosing the ESNI queries and response content to the local
resolver provides it with information that it could not otherwise get.
Thus, privacy risk.

> typo,  I meant to write: "to which there is not a known privacy statement"

Yes. Leaving aside the discussion of privacy statements, the privacy
exposure comes from disclosing the target site hidden in the ESNI.

-- Christian Huitema

---

From: Rob Sayre <[email-masked]>
Date: Tue, 24 Dec 2019 16:38:23 -0800

> network/DHCP server indicates".

Here is a fun case I recently encountered. At Los Angeles International
Airport, DHCP pointed at Google DNS, and macOS dutifully sent unencrypted
queries there. Firefox ignored that and sent encrypted DNS queries to
Cloudflare. Both DNS resolvers are centralized, but one is configured via
DHCP and unencrypted. Screenshots attached :)

thanks,
Rob

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 27 Dec 2019 10:23:40 +0100 (CET)

> Il 24/12/2019 21:09 Christian Huitema <[email-masked]> ha scritto:
> 

I am in favour of this, it is more or less what I meant by documenting the use cases, so that you can then discuss them and their threat models.

> Personally I believe there is a difference between retrieving  an A or AAAA record and retrieving an ESNI record. Resolving the first one locally may well be convenient. Resolving the ESNI locally…

This depends whether you trust the local server more or less than the remote one. If we consider the idea of "resolverless DNS", it also depends on your tradeoff between privacy and performance, since even in those cases in which the remote server provides you with better privacy, having a local resolver provides you with caching, with query aggregation and (generally) with lower response times. By the way, this is also why any solution needs to be analysed under multiple dimensions and not just privacy.

--

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Dec 2019 08:13:22 -0500

Can you explain what you mean by “you” and “your” here?

> On Dec 27, 2019, at 04:23, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
>

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 27 Dec 2019 14:22:40 +0100 (CET)

> Il 27/12/2019 14:13 Ted Lemon <[email-masked]> ha scritto:
>  

"You" the (impersonal) user.
--

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Dec 2019 09:18:36 -0500

> "You" the (impersonal) user.

It might be helpful to refer to specific use cases, then. There are a lot of different participants in the configuration process whom we might call “you,” and it gets confusing if you aren’t specific.

Even if we mean “the operator of the host,” that’s still not very specific, since there are a lot of different kinds of operators of hosts with different needs, and lots of different types of hosts with different operational characteristics.

---

From: Andrew Campling <[email-masked]>
Date: Sat, 28 Dec 2019 18:46:46 +0000

On Dec 27, 2019, at 14:19, Ted Lemon <[email-masked]> wrote:

> It might be helpful to refer to specific use cases, then. 

I think that a key requirement of the working group is to ensure that use cases are properly documented.  At present there are somewhat nebulous references to undefined, or certainly undocumented, use cases; the lack of such documentation makes it impossible to properly assess the impact of different approaches on them.  

Andrew

---

From: Rob Sayre <[email-masked]>
Date: Sat, 28 Dec 2019 22:43:45 -0800

On Sat, Dec 28, 2019 at 10:47 AM Andrew Campling
<[email-masked]> wrote:

> I think that a key requirement of the working group is to ensure that use
> cases are properly documented.  At present there are somewhat nebulous
> references to undefined, or certainly undocumented, use cases; the lack of
> such documentation makes it impossible to properly assess the impact of
> different approaches on them.
>

Another point of view is that the word "properly" in this message is not
meaningful, and the references to "use cases" and "impact" are similarly
lacking.

The IETF published a few different ways of encrypting DNS. We're now
encountering the predictable results of doing so (e.g. obsoleting
intermediaries that rely on interception of unencrypted traffic).

That doesn't call for backtracking. In any case, the IETF doesn't make
rules.

thanks,
Rob

---

From: Melinda Shore <[email-masked]>
Date: Sat, 28 Dec 2019 22:10:13 -0900

> meaningful, and the references to "use cases" and "impact" are similarly

About a decade ago the IETF fell into a problem statement (use cases)/
framework document/gap analysis/eventually-getting-around-to-working-on-
protocols rut and it does not appear to have improved the quality of
our work.  Fortunately that pattern seems to have fallen out of favor.

I do think that it's critical to be clear about what problem(s) you're
trying to solve, though, which seems likely to include a description
of deployment environments, etc.  But it seems necessary to me for any
such text to lead directly to "This is the specific problem I'm trying
to solve."

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Andrew Campling <[email-masked]>
Date: Mon, 30 Dec 2019 23:01:24 +0000

On Sun, Dec 20, 2019 at 6:44 AM Rob Sayre <[email-masked]>  wrote:

> Another point of view is that the word "properly" in this message is not meaningful,
> and the references to "use cases" and "impact" are similarly lacking.

What wording would help to make this more meaningful for you?

> The IETF published a few different ways of encrypting DNS. We're now encountering
> the predictable results of doing so (e.g. obsoleting intermediaries that rely on interception
> of unencrypted traffic).

I note that several people have suggested that ISPs routinely use DNS data to track and monetise their customers without offering any meaningful, current evidence to back up their assertions.  I know that this isn’t in reality an issue in Europe due to GDPR, along with other jurisdictions that have adopted equivalent legislation.  In addition, I note that US ISPs like Comcast have published commendably clear privacy policies with regards DNS (see https://corporate.comcast.com/stories/privacy-with-comcasts-xfinity-internet-service).   Perhaps people are relying on old data or anecdotes?

Andrew

---

From: Rob Sayre <[email-masked]>
Date: Mon, 30 Dec 2019 16:00:53 -0800

On Mon, Dec 30, 2019 at 3:01 PM Andrew Campling
<[email-masked]> wrote:

> meaningful,

I don't think there is alternate wording that would make the proposed WG
productive.

> encountering
> I note that several people have suggested that ISPs routinely use DNS data
> to track and monetise their customers without offering any meaningful,
> current evidence to back up their assertions.
>

Here is a lobbying letter from an industry association:
https://www.ncta.com/sites/default/files/2019-09/Final%20DOH%20LETTER%209-19-19.pdf

It is from September 19th, 2019. It mentions advertising explicitly. There
are numerous press articles about this letter, so I won't delve further
into its contents.

> I know that this isn’t in reality an issue in Europe due to GDPR, along
> with other jurisdictions that have adopted equivalent legislation.
>

Any intermediary can monetize the data, not just ISPs. For example, here is
a Cisco product:

https://umbrella.cisco.com/products/our-intel

"Umbrella gathers 200 billion internet requests from over 100 million
enterprise and consumer users across 190 countries every day at the moment
a request is made. Our real-time DNS data is also enriched with diverse
public and private data feeds."

I'm assuming those 190 countries include jurisdictions where GDPR applies.
While that product seems well-intentioned, the data is being aggregated and
used without consent.

> In addition, I note that US ISPs like Comcast have published commendably
> clear privacy policies with regards DNS (see
> https://corporate.comcast.com/stories/privacy-with-comcasts-xfinity-internet-service).
>  Perhaps people are relying on old data or anecdotes?
>

I think Comcast's (new) policy is pretty good, to be honest. I do wonder
why they're not in Mozilla's TRR program, though.

thanks,
Rob

---

From: "John Levine" <[email-masked]>
Date: 30 Dec 2019 21:01:23 -0500

>are numerous press articles about this letter, so I won't delve further

The letter you linked to is two pages of FUD accusing Google of
planning to do all sorts of terrible things without a shred of
evidence.  It is flatly contradicted by Google's own statements about
their DoH deployment plans.

I'm not saying Google is perfect, but I don't find hostile telecom
lobbyists to be a useful source of advice about their intentions.

I hope we can agree there's nothing to see there.

R's,
John

---

From: Rob Sayre <[email-masked]>
Date: Mon, 30 Dec 2019 18:08:05 -0800

On Mon, Dec 30, 2019 at 6:01 PM John Levine <[email-masked]> wrote:

> In article <CAChr6Sxm2GuHFTqOjtq=
> [email-masked]> you write:

I can't say I disagree with your assessment.

But, the letter does mention that encrypted DNS might harm competition in
the advertising space. The actual text is:

"This could inhibit competitors and possibly foreclose competition in
advertising and other industries."

How could encrypted DNS harm competition in advertising if unencrypted DNS
weren't being used for advertising?

thanks,
Rob