On Wed, Dec 18, 2019 at 7:06 AM Sara Dickinson <sara@xxxxxxxxxxx> wrote:
> On 2 Dec 2019, at 00:00, Martin Thomson <mt@xxxxxxxxxxxxxx> 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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
