On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson <[email protected]> wrote:
> > > > 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. > I can't say I like this very much. > > “It has been pointed out that should the trend towards using large public > resolvers increase, an increased centralisation of DNS resolution services > will result. > Well, it's been pointed out, but it's not at all clear that it's true, due to the large amount of centralization of ISPs in certain areas, so no, I don't think this document should make this claim. 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]. > I'm not sure what the point of this text is, but it seems kind of confusing. In particular, it's not the case that the primary reason that Firefox uses a hardcoded list is because there is no standardized discovery mechanism. Everything after this just seems to pre-empt discussions that are ongoing and haven't reached consensus. > 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
