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

[Patrick McManus <[e-mail]>]

On Mon, Jun 18, 2018 at 12:36 PM, Sara Dickinson <[e-mail]> wrote:

>
>
> On 18 Jun 2018, at 15:25, Patrick McManus <[e-mail]> wrote:
>
> In the interest of moving forward, given that we've completed wglc a
> couple of times, I'm going to incorporate this as a ietf last-call comment
> and include text as part of that cycle.. there is surely something useful
> that can be written
>
>
> Erm, did you mean IESG not IETF LC?
>
>
I think we're talking about the same thing. After the WG shepherd submits
the doc to the iesg, they will issue a ietf-wide last call. We can make the
additions we're talking about here as part of those inevitable updates.


>
> in the big picture, this is something that I would like to see handled by
> BCP56-bis, but doesn't seem to be addressed at all there. That's probably a
> good comment for that draft.
>
> some more specific things to consider when writing text that come to my
> mind:
> * content negotiation is something doh clients will want to do as a normal
> part of http, and most of this information is related.. e.g. accept-language
> * many headers leak state but are tied to http features that clients might
> choose to participate in anyhow (e.g. cache revalidation headers)
> * versioning information helps prevent bugs from becoming defacto features
> forever.
> * authentication is a normal thing to do
> * there are lots of headers that we don't know about - and that's ok.
> Let's provide advice rather than be a whitelisting firewall.
> * entities other than DoH clients and DoH servers participate in a DoH
> exchange (proxies, lb, etc) so be aware that there is an asymmetry between
> send and recv in this spec. (i.e. you can say a DoH client cannot send Foo,
> but you cannot say that a DoH server receiving Foo is a protocol error
> because generic HTTP in between might add it.)
>
>
> Thanks for the list… it certainly provides context to understand that HTTP
> as a substrate brings a significant overhead (as well as all the benefits
> of such bells and whistles).
>
> So I think what I am hearing here is that the use of DoH effectively comes
> at the price of accepting that additional overhead and all its potential
> privacy/tracking issues because in practice it is rather impossible and/or
> impractical to have ‘bare’ DoH that transmits only as much information
> about the user as, for example, typical DNS-over-TLS?
>


more impractical than impossible - at the extreme, you would be building a
mere tunnel rather than really building an HTTP application. But its
totally appropriate to highlight that there are various tradeoffs that can
be made by implementations. e.g. firefox will not accept server cookies
right now on DoH transactions nor will it allow authentication. But, in a
different circumstance, a DoH client might want to use cookie-drive auth
totally reasonably (imagine a subscription based DoH service) - so its not
something the protocol should prohibit but we can mention.


>
> I see the trade-offs here, I just want to make sure I understood
> correctly….
>
>
> wrt Sara's specific comment about the differences between connection
> contexts - that's not a difference the core semantic layer of HTTP
> presents. from that pov HTTP is stateless. its often not something the
> client interface exposes very well, and is certainly not necessarily an end
> to end property. So any text in that neighborhood probably needs to be
> along the lines of fyi.
>
>
> So I think DoH will need to say something fairly generic along the lines
> of "think about the meta data tradeoffs and explicitly enable features you
> need”.
>
>
> So from a privacy point of view there is no clear way at the protocol
> level to separate DoH traffic from other HTTPS traffic? In other words any
> considerations of data minimisation would have to be framed in that context
> (i.e. DoH traffic can’t necessarily be isolated)?
>
>
I think you're right - especially when you consider the "HTTP chain" is
more than just the originating client. Also note that mixing has very good
sides for privacy as well - indeed while there are pros and cons I think
mixing is a net good. (it deters traffic analysis, it minimizes handshakes
and sni, etc.. while separation tends to be more easily defeated by IP
analysis or behavioral correlation by the terminating server)