Subject: [dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Wed, 07 Oct 2020 18:43:40 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-dprive-rfc7626-bis-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

== Section 1 ==

"At the time of writing, almost all this DNS traffic is currently sent
   in clear (i.e., unencrypted).  However there is increasing deployment
   of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484],
   particularly in mobile devices, browsers, and by providers of anycast
   recursive DNS resolution services.  There are a few cases where there
   is some alternative channel encryption, for instance, in an IPsec VPN
   tunnel, at least between the stub resolver and the resolver.

   Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
   This has practical consequences when considering encryption of the
   traffic as a possible privacy technique.  Some encryption solutions
   are only designed for TCP, not UDP and new solutions are still
   emerging [I-D.ietf-quic-transport] [I-D.huitema-quic-dnsoquic]."

This text made me wonder about the value of publishing this bis document at
this point in time. Things are evolving so rapidly that, with respect to
several of the new parts of this document (e.g., the last few paragraphs of
Sec. 6.1.1, Sec. 6.1.1.1, Sec. 6.1.1.2), an immutable summary designed to
represent reality over the long term doesn't really seem feasible right now.
Why not wait to see how QUIC, DOH, ADD, ODNS, etc. shake out in the next few
years and take this up then?

== Section 6.1.1.2 ==

"Users will only be aware of and have the ability to control such
   settings if applications provide the following functions:

   o communicate clearly the change in default to users

   o provide configuration options to change the default

   o provide configuration options to always use the system resolver"

This doesn't seem true. If the third bullet isn't provided, users still have
awareness and control. Also, the bullets seem redundant with the text above, as
if this is saying "users only have awareness and control if they have awareness
and control." As a result I'm not sure what this text is really meant to convey.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please remove uses of "us" and "we," given that this is a consensus document.

"Privacy policies for these servers may or may not be available and users need
to be aware that privacy guarantees will vary with network." --> This is
unrealistic as almost no users understand any of this. I'd recommend removing
this.

Section 6.1.3: The title says "Blocking of User Selected DNS Resolution
Services" but the text is actually broader than that and applies to blocking of
resolution services whether or not they are user-selected. I would suggest
changing the title.

Section 6.1.4.2:
"Privacy focused users should be aware of the potential for additional client
identifiers in DoH compared to DoT and may want to only use DoH client
implementations that provide clear guidance on what identifiers they add."
Again this seems really unrealistic for the majority of users who have no idea
what any of this means.

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 9 Oct 2020 14:07:31 -0400

Alissa,

> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
The consensus of the WG was that enough changes have occurred since the
first document was published that it made sense to collect those details in
one place.  One could easily argue that this space is rapidly evolving, so
to say "let's just wait..." could be a never ending wait. Publishing this
document now allows the community to agree on the current state of affairs
that can help it focus on the critical next steps.

(Now saying that, we lack a summary narrative which lays all those out.
Which has been added).

== Section 6.1.1.2 ==
> and control." As a result I'm not sure what this text is really meant to

First. Another comment changed the first bullet to be:

  "communicate clearly the change to users when the default application

     resolver changes away from the system resolver"

Now these bullets are in relation to an application.   We could update the
second two bullet points to be something like this:

  o  provide configuration options to change the default application
resolver

  o  provide configuration options to allow the application to always use
the system resolver

Thanks. I believe I found them

"Privacy policies for these servers may or may not be available and users
> need
"user" in this case is an individual but is also meant to represent
"administrator

of computing resources" such as in an enterprise environment, etc.

> resolution services whether or not they are user-selected. I would suggest
Would "Altering of User Selected DNS Resolution Services" work in this case?

> Again this seems really unrealistic for the majority of users who have no
Once again, "user" here is a broad term to mean more than Joe Q. Public,
but someone who has administrative oversight on computing resources.

thanks
tim