[dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

["Martin Thomson" <[e-mail]>]

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.

Section 2

> This document does not attempt a comparison of specific privacy protections provided by individual networks or organisations, it makes only general observations about typical current practices.

Having been called out here, I would question whether this claim is indeed correct.

BTW, what is "HTTPS destination IP address fingerprinting"?  Was the intent of this paragraph to say that this document only examines the DNS protocol independent of the greater context in which it is used?  That is, it looks at DNS without considering how privacy risks might result from the use of DNS in combination with other protocols?

Section 3.4.2

This section appears to address several related issues around the use of TLS primarily: fingerprinting, identification, and linkability (the document uses the word "correlation" in line with RFC 6973).  There are parts where fingerprinting is equated with identification or linkability in ways that appear confused.

For instance,

> The use of clear text transport options to optimize latency may also identify a user, e.g., using TCP Fast Open with TLS 1.2 [RFC7413].

The use of TFO is a linkability issue, not an identification one.  TFO can also be used without encrypted transport.

However, this seems overly negative. Resumption and TFO cookies - and therefore any linkability they might provide - is discretionary on the part of clients. You might (as is done later) raise the question here about the competing concerns of individuals and implementations, but that's a meta-level question that I'll get back to.

As a minor note here, TLS 1.3 resumption also provides a server with the ability to link sessions.  This document seems to assume that this is a property of TLS 1.2 only, which is incorrect.  There are proposals that might allow for unlinkable resumption, but those are still just proposals.

Also on linkability and identification:

> Certain configuration options for encrypted transports could also in principle fingerprint a user or client application.

Though there are definitely ways in which the listed options contribute to fingerprinting, the paragraph talks about session resumption, where the concern is primarily linkability.  Mixing these concepts only serves to confuse rather than enlighten.

When it comes to fingerprinting, it's important to distinguish between an ability to identify the software in use (Windows vs. Linux, Safari vs. Chrome) and the ability to distinguish different users.  The text here conflates these notions in an unhelpful fashion. The fingerprinting highlighted is a result of characteristics inherent to the software, not user-specific details.

For the most part, we (as protocol designers) accept that distinguishing software is possible and we don't generally attempt to erase differences that only serve to reinforce those signals. Suppressing differences in wire image across implementations generally runs counter to the desire for diversity in implementation choices.  This text - perhaps unintentionally - takes the somewhat sensational position that distinguishing between FreeBSD and Solaris is as relevant as the sort of fingerprinting that might be used to isolate individuals.  It does that by concentrating on choices that are usually made by implementations not individuals.

This is where a clear recognition of the distinction between implementation choices and how implementations represent (or maybe don't represent, if that is the way you feel) the choices of individuals requires a little more care.  I don't know how easy it is to engage on that topic without also engaging with the current debate though.

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.

Section 3.5.1.2

I admit that I don't understand the purpose of this section. Concentrating on minutiae, like the details of DHCP or ARP/NDP spoofing, is far too low level. If we were to simply assume the usual threat model [RFC3552], then the conclusions here are obvious: if you fail to authenticate the server, then you get the server that an attacker chooses.

I would remove this section in favour of improving Section 3.5.1.4, which addresses the most pertinent question.

Section 3.5.1.3

The arguments here again fall under an area of active debate. The second paragraph makes the claim that in-network blocking of encrypted DNS might be done for reasons that benefit users. That relies on a number of unstated assumptions. More seriously, this particular subject is one of the most contentious parts of the current debate and it has no place in a document that purports to represent community consensus.

Either way, I think that RFC 7754 has a far better treatment of the broader topic.  This section might be better served with a reference to that.

Section 3.5.1.4

Again, this might be too close to the current debate, but I find it odd that there is no connection drawn between authentication of resolvers and choosing the resolver that receives the potentially privacy-sensitive information in queries. This choice is the single overriding issue upon which the entirety of the difficult debate depends.  Maybe there was a conscious decision to gloss over the point to avoid the controversy.  Given the significance of this point to the topic, I don't see how it can be avoided.

There's an unstated assumption throughout the document that the best defense for privacy is some form of active choice or at least informed consent on the part of end users. That too is an area where there is some contention.

Section 3.5.1.5.1

The arguments here repeat those from Section 3.4.2 (nit: not 3.4 as stated).  A section reference would be enough.

Section 3.5.1.5.2

I can't see anything in this section that Section 8 of RFC 8484 doesn't already say.

The text here does claim that the use of DoH rather than Do<other> is a choice to trade privacy for some other vaguely-defined property, which I might read as convenience. It is hard to read the extended treatment of this as anything other than prejudicial.  For instance, by labeling DoH as complex and requiring of detailed analysis, it implies that there are unstated intricacies that are traps for the unwary. This document is intended to demystify the privacy properties of DNS as a whole, so would it not be better to explain what the essential properties are?

The one new piece is the claim that there is fingerprinting information inherent to the use of HTTP.  While there is perhaps some merit in the argument that a narrow range of options for encoding the same semantics produce less variance, it is not clear that DNS is any more free of this sort of variance than HTTP.  Maybe HTTP has more options for the creation of side channels, but DNS isn't free of those. Aside from the Accept-Language thing - which RFC 8484 addresses - I believe that these leaks are implementation-specific and rarely an individual-specific choice, but the document strongly implies that there is a risk to individual privacy.  If that is indeed the claim, it could be made directly in more concrete terms.