> On 31 Dec 2019, at 14:45, Eric Rescorla <e...@rtfm.com> wrote: > >
> On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson <s...@sinodun.com > <mailto:s...@sinodun.com>> wrote: > > >> On 2 Dec 2019, at 00:00, Martin Thomson <m...@lowentropy.net >> <mailto:m...@lowentropy.net>> 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. > > Ah, well, then I certainly wouldn't call this HTTPS-anything, given that it's > a feature of basically every protocol. It just comes up more in the HTTPS > context because we're otherwise encrypting the traffic. > > I would say > "The privacy risks associated with other protocols that make use of DNS > information are not considered here” That works. > > >> >> 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].” > > Sure. > > >> >> 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:… > > I don't generally think that documents like this ought to predict how > implementers will behave, so I would remove this text entirely. But one of the points of this document is to describe the actual use of DNS so discussing implementation behaviour seems within scope. Given many of the implementations of DoT are done by DNS developers who might be implementing TLS for the first time highlighting potential privacy considerations with such implementation choices also seems relevant. > > On the surface, this actually seems like quite a good setting for *not* using > TLS session resumption (or TFO, or 0-RTT). Consider a browser, in which > you're likely going to want to connect to the DoH server on startup and keep > that connection open as long as you are doing just about anything that would > cause DNS resolution. You might disconnect when you go really idle, but then > you could get warm again quickly when the user re-engages, at which point you > probably can just accept an extra RT (remember that user response is quite > slow). This isn't something that we have spent a lot of time optimizing, I > don't think, so I suspect there's still a fair bit of work to do to figure > out the best pattern. In any case, making recommendations here seems > premature. Where is a recommendation made? I _think_ the text just describes the issue - please suggest text otherwise. I agree with Vittorio’s follow up comment about at least including a description of the issue - the abstract of this document states “It is intended to be an analysis of the present situation and does not prescribe solutions. " > > > If libraries or applications offer user configuration of such options (e.g. > [stubby]) then they could in principle help to identify a specific user.” > > This seems true, but TBH kind of a niche case. General experience is that > people don't change defaults very much, so the real guidance is "don't change > defaults so you can hide in the crowd” Suggest adding “Users may want to avoid changing such options to avoid this issue." > > >> >> 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. > > Well, as MT says, this is just the 3552 threat model. The basic fact is that > you need a reference to a server that is (1) securely obtained and (2) > verifiable against the server itself. Absent that, you are subject to attack > by the network. Suggest adding a sentence at the start of the section “[RFC3552] provides guidelines for describing Internet threat models. This section specialises the discussion to the case of DNS resolver configuration.” Sara.
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
