> On 2 Dec 2019, at 00:00, Martin Thomson <[email protected]> wrote: > > Prompted by my surprise at seeing Brian Trammell's mention of a '[firefox]' > reference in this document, I reviewed the contents of this draft more > closely. > > Summary > > I found a number of issues with the additions in this -bis document. Of > particular concern is Section 3.5.1 (formerly Section 2.5.1 in RFC 7626), > which has been expanded from one paragraph to four pages. That there is a > need for new content here is clear. One thing that has become very clear is > that our understanding of the role of recursive resolvers has evolved a lot > in the past year. However, I don't believe that the current text is a fair > representation of the problems we're facing. Right now, the community is in > the middle of highly contentious debate on the general topic, and I don't > think that the new content reflects consensus. > > It does appear as though there is an attempt here to address the invariant > technical characteristics without engaging more controversial positions. I > don't believe that has been successful. The effect is to preempt an active > area of contention. > > I am opposed to the IETF publishing this document in its current form. > >
Attempting to address both Martin and Ekr’s comments on section 3.5.1.1. here... > > > Section 3.5.1.1 > > This section references announcements of product plans that will eventually - > even by the time that this document is published - be outdated. This is, in > my view, the most controversial section of the document, and it is all based > on somewhat tenuous information. > > All the "at the time of writing" text in this section would need to be > removed in order for me to be comfortable with the publication of this > document. > > Similarly, I find the following text problematic: > >> If applications enable application-specific DNS settings without properly >> informing the user of the change (or do not provide an option for user >> configuration of the application's recursive resolver) there is a potential >> privacy issue; depending on the network context and the application default, >> the application might use a recursive server that provides less privacy >> protection than the default network-provided server without the user's full >> knowledge. > > This text presumes a great deal about the environment into which these > applications are being deployed. It appeals to a status quo bias by > examining an area of a larger change that might have negative consequences > without regarding the effect in the aggregate. Moreover, it sets unrealistic > expectations - "the user's full knowledge" - about what might an application > might need to do in order to make these deployment decisions. In other > words, whether it was intended or not, this takes a firm stance on the > current rather contentious debate. > > Separately, I appreciate that some people believe that these developments > signal a move toward greater centralization of the DNS service, but that too > is the subject of the ongoing debate. > > Maybe there is a version of this section that the IETF can publish, but not > until we actually have consensus on these subjects. I have to most > strenuously object to any attempt to publish a document if this section > remains. Suggest replacing the last 4 paragraphs of this section with the following text. “It has been pointed out that should the trend towards using large public resolvers increase, an increased centralisation of DNS resolution services will result. An increasing number of applications are offering application-specific encrypted DNS resolution settings, rather than defaulting to using only the system resolver. Due to a lack of a standardized discovery mechanism for DoH and Strict DoT servers, applications that do so are currently limited to using hard coded lists of resolvers and a variety of heuristics and resolvers are available in different applications. At the time of writing, efforts to provide standardized signalling mechanisms for applications to also discover the services offered by local resolvers are in progress [I-D.ietf-dnsop-resolver-information]. Note that an increasing numbers of ISPs are deploying encrypted DNS, for example see the Encrypted DNS Deployment Initiative [EDDI]. Application-specific changes to default destinations for users' DNS queries might increase or decrease user privacy - it is highly dependant on the network context and the application-specific default. This is an area of active debate. In order that users are aware of and can control such changes it is highly desirable that applications * communicate clearly the change in default to users * provide configuration options to change the default * provide configuration options to always use the network provided resolver The IETF is working on a number of issues related to application-specific DNS settings. For example there have been discussions on the IETF ADD mailing list [ADD] and a proposal for a new ABCD working group [ABCD].” Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
