Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03

[Eric Rescorla <[e-mail]>]

On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson <[e-mail]> wrote:

>
>
> On 2 Dec 2019, at 00:00, Martin Thomson <[e-mail]> 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.  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"


>
> 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.

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.


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"



> 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 ‘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.

-Ekr