Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS

[Erik Nygren <[e-mail]>]

On Tue, Jun 19, 2018 at 11:03 AM, Sara Dickinson <[e-mail]> wrote:
>
>
> 2. Implementors should evaluate what identifiers could be omitted or be
> made less identifying while still fulfilling the protocol's goals.
>
>   a. Specifically, implementors SHOULD not use non-essential HTTP headers
> in DoH messages and SHOULD set the user agent string to ‘DoH client’.
>
>   b. Implementations SHOULD only accept cookies or allow client
> authentication when it is required to fulfil the protocols goals (e.g. a
> subscription service with user opt-in).
>

I'd think we'd want to avoid normative language in the Privacy
Considerations?
We should be careful about what "non-essential HTTP headers" mean,
especially without being much more specific about these. and providing
clear guidance in the core specification.  Implementations leaving out
required headers without clear guidance seems likely to lead to
interoperable implementations.

Separately on privacy considerations...

>From a related thread on DNSOP where Colm MacCárthaigh raised this, do we
need to provide guidance on the rrset ordering side-channel?  Or does that
apply as a general issue for DPRIVE?  The relevant issue is that since
cached rrset responses will have a stable ordering of IP addresses to try,
if clients receive the same rrset over DoH and go through the IPs in the
same order, this makes it visible to an external observer which cached
response the two clients received, especially if the same set of IPs share
a wide variety of different hostnames.   Recommending the client permute
the (unordered-by-specification) rrset received and try responses in a
pseudo-random order (absent local performance information preferring some
over others) both reduces opportunities for this side-channel attack.
Regardless of the side-channel privacy issues here, since DoH responses may
be cached by design and won't get randomized/roundrobin/etc rrset-sorting
applied to each response it likely makes sense to give the guidance that
DoH clients should do pseudo-random sorting of received rrsets of only for
better load balancing across IPs in the rrsets.

     Erik