On Tue, Dec 31, 2019 at 8:33 AM Vittorio Bertola < [email protected]> wrote:
> > Il 31/12/2019 15:45 Eric Rescorla <[email protected]> ha scritto: > > > > > On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson < [email protected]> 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
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
