Re: Alt-Svc Privacy Concerns

On Sun, Apr 10, 2016 at 5:47 AM, Matthew Kerwin <matthew@kerwin.net.au>
wrote:

> On 10/04/2016 4:33 AM, "Phil Lello" <phil@dunlop-lello.uk> wrote:
> >
> > This is a slightly different issue than the described scenario, and I'm
> far from certain that the risks are adequately highlighted there.
> >
> > "By using unique names, servers could conceivably track client
> requests." seems incredibly weak to the point of being dismissive, since it
> suggests a per-client hostname being generated, and that it's incredibly
> unlikely anyone would bother.
> >
> > IMHO, it's quite likely that multiple seemingly unrelated sites operated
> by the same entity might legitimately converge users to a common
> servername. It's quite likely that at this point that the user agent would
> see these as candidates for sharing the same connection. It seems
> reasonable that there should at least be a recommendation for a user agent
> to warn users that there is significant potential for being tracked, and
> gain consent.
> >
>
> This sounds like a UX thing -- incognito sessions oughtn't reuse
> connections for different URI hostnames, even if the alt-svcs point to the
> same name. The consent, then, is not being incognito.
>

The primary justification I've read (both on IETF lists and industry
forums) for TLS-by-default and retiring HTTP-over-TCP boils down to not
trusting users to make security decisions for themselves. I don't see why
an inconsistent philosophy should be taken here.

Given the history and motivation for the 2011 EU Directive on cookies, I
don't think that would be viewed as sufficient consent, and this could be
interpreted as bypassing the intent of the law (but let's not engage in too
much debate here, that's a job for the law makers).

> Is it worth documenting this risk/advice somewhere, or is it already
> self-evident?
>
Given previous IETF standards and subsequent abuses (going back at 1981's
RFC 791 and Strict Source Routing), I don't think self-evident is good
enough.

IMHO, the UX aspects need documenting, for the following reasons:

 - It is presumably intended that the server certificate for the Alt-Svc is
matched on Host and not Alt-Svc
 - It is reasonable to assume that with Alt-Svc, a user agent will continue
to display the original URI to avoid confusion (and because correctly
displaying both Alt-Used and Host in the URI would be ugly and confusing).
 - When viewing the certificate for a resource, the user agent needs to
choose between the chain for the Alt-Svc, which won't necessarily match the
original URI, the chain for the original URI, which misrepresents the
source of the information, or both chains, which will require further user
education.

There appears to be a conflict when using Alt-Svc over TLS between keeping
information secret and respecting user privacy. Given that the IETF has
adopted a position on the former, it seems essential to adopt one on the
latter.