On 7 Jan 2020, at 22:51, Eric Rescorla < ekr@xxxxxxxx> wrote:
On 31 Dec 2019, at 14:45, Eric Rescorla < ekr@xxxxxxxx> wrote:
<snip>
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.
There are two problems here:
1. That you are making predictions about what people will do and that those preductions are unsupported by evidence. That needs to go.
If you are talking about the specific text above - are you saying you don’t believe any existing implementations of encrypted DNS transports re-use sessions? If so, I can add the list of ones that do to the document. Or you believe they all use the same default configuration options? If not what is the specific prediction you mean?
2. That you are covering material that is already better covered in 8484, so why are you duplicating it?
Because this is a general overview of all DNS protocols, RFC8484 is by its nature a DoH specific treatise.
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. "
To repeat my question from before: this material is already in 8484, so why are you trying to write a new document that duplicates that?
As above.
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."
Sure, OK.
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.
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.”
Well, that's a start, but the problem is still that it's too low level. If you insist on having this section, you should lay out the implications of the situation rather than (or at least in advance of) digging into the details.
The level is detail is entirely comparible to that in the original RFC (much of the text is still the same). As I said to Martin, the section focusses on the impact on the DNS resolution path that results from the attack: diversion of traffic and traffic capture. Are there other implications you think should be included? Please suggest text.
Sara.
|
