> 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. >
Martin, To try to separate out the issue with the text in Section 3.5.1.1 I’ll respond to the comments on that in a separate thread and try to address the other issues in this email. > > 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? It is describing the ability to fingerprint the website a user connects to based just on the IP address of the HTTPS traffic. For example, this paper given at ANRW https://dl.acm.org/authorize?N687437 <https://dl.acm.org/authorize?N687437>. Please suggest text if you prefer a different description of this issue. > > 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. Suggest: OLD: “The use of clear text transport options to decrease latency may also identify a user e.g. using TCP Fast Open [RFC7413]." NEW: “Note that even when using encrypted transports the use of clear text transport options to decrease latency can provide correlation of a users' connections e.g. using TCP Fast Open [RFC7413].” > > 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. Suggest: OLD: “Users of encrypted transports are also highly likely to re-use sessions for multiple DNS queries to optimize performance (e.g. via DNS pipelining or HTTPS multiplexing). Certain configuration options for encrypted transports could also in principle fingerprint a user or client application. For example: …." NEW: “Implementations that support encrypted transports are also highly likely to re-use sessions for multiple DNS queries to optimize performance (e.g. via DNS pipelining or HTTPS multiplexing). Default configuration options for encrypted transports could in principle fingerprint a specific client application. For example:… If libraries or applications offer user configuration of such options (e.g. [stubby]) then they could in principle help to identify a specific user.” After a quick scan I don’t think there are other cases of word/concepts being used incorrectly but if you think there are then please do suggest text. > > Section 3.5.1.1 > <snip> > > 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. RFC7626 included Section 2.5.3 https://tools.ietf.org/html/rfc7626#section-2.5.3 <https://tools.ietf.org/html/rfc7626#section-2.5.3> ‘Rogue Servers’. This section is just an update of that text to improve context and remove the phrase ’rogue server’. Since the majority of OS implementations still use these mechanisms today it seems to still be relevant. > > 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. Suggest the following text with the goal of getting consensus that the opinion exists and is held by many network operators, not that the opinion itself has consensus: OLD: “ In some cases, networks might block access to remote resolvers for security reasons, for example to cripple malware and bots or to prevent data exfiltration methods that use encrypted DNS communications as transport. In these cases, if the network fully respects user privacy in other ways (i.e. encrypted DNS and good data handling policies) the block can serve to further protect user privacy by ensuring such security precautions." NEW: “ Many network operators argue that they block access to remote resolvers for security reasons, for example to cripple malware and bots or to prevent data exfiltration methods that use encrypted DNS communications as transport. Further discussion of Internet service blocking and filtering can be found in [RFC7754]." > > 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. The intent of this section is literally just a clarification of the security properties of DoH/Strict DoT vs Opportunistic DoT/Do53, nothing more. I suggest moving this text to the end of section 3.5.1.2 to put it solely in the context of attacks on configuration. > > 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. I’ll update the section reference and remove the last sentence and the two bullet points. > > 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. Suggest: OLD: “The picture for privacy considerations and user expectations for DoH with respect to what additional data may be available to the DoH server compared to DNS over UDP, TCP or TLS is complex and requires a detailed analysis for each use case. In particular the choice of HTTPS functionality vs privacy is specifically made an implementation choice in DoH and users may well have differing privacy expectations depending on the DoH use case and implementation.” NEW: “Users should be aware that the particular choice of HTTPS functionality vs data minimisation (for example, whether to include the user-agent header) is an implementation specific choice in DoH, not one defined in RFC8484.” Sara.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
