Alissa, On Wed, Oct 7, 2020 at 9:43 PM Alissa Cooper via Datatracker < nore...@ietf.org> wrote:
> 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? > > 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 == > > "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. 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 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please remove uses of "us" and "we," given that this is a consensus > document. > > Thanks. I believe I found them "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. > > "user" in this case is an individual but is also meant to represent "administrator of computing resources" such as in an enterprise environment, etc. > 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. > > Would "Altering of User Selected DNS Resolution Services" work in this case? > 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. > > 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
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
