On Tue, Dec 31, 2019 at 8:33 AM Vittorio Bertola <vittorio.bertola@xxxxxxxxxxxxxxxx> wrote:
Il 31/12/2019 15:45 Eric Rescorla <ekr@xxxxxxxx> ha scritto:
On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson < sara@xxxxxxxxxxx> wrote:
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.As I understood it, the purpose of this document is to map possible DNS-related privacy issues, and not necessarily to address them with recommendations (and in that case you are right that there might be a privacy vs performance tradeoff). So the starting point here was to state that a privacy risk exists, even if we are not ready to make recommendations (which may come in the future in a "7626ter" document) or even to assess whether the risk is big enough to even need recommendations (which, I agree, will greatly depend on what implementers will do).
On the other hand, I think there is agreement (is there?) that encrypted DNS protocols introduce specific tracking opportunities deriving from how they open and reuse connections and from other features of the encrypted transport mechanism, so it would be weird to omit this risk from the analysis..
This analysis is already covered extensively in RFC 8484, Section 2. Rather than trying to rephrase it here, I would recommend linking to that.
-Ekr
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
