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

Alissa Cooper via Datatracker <noreply@ietf.org> Thu, 08 October 2020 01:43 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dns-privacy@ietf.org
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF58C3A0A40; Wed, 7 Oct 2020 18:43:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dprive-rfc7626-bis@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, Brian Haberman <brian@innovationslab.net>, dns-privacy@ietf.org, brian@innovationslab.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <160212142076.12259.17590774442239950703@ietfa.amsl.com>
Date: Wed, 07 Oct 2020 18:43:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/KMTGqASBG7vf3cWdoMRMpu0MiHQ>
Subject: [dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2020 01:43:41 -0000

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.