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

[Eric Rescorla <[e-mail]>]

On Tue, Dec 31, 2019 at 8:33 AM Vittorio Bertola <
[e-mail]> wrote:

>
> Il 31/12/2019 15:45 Eric Rescorla <[e-mail]> ha scritto:
>
>
>
>
> On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson < [e-mail]> 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