Re: Alt-Svc Privacy Concerns

[Matthew Kerwin <[e-mail]>]

On 10/04/2016 9:06 PM, "Phil Lello" <[e-mail]> wrote:
>
> On Sun, Apr 10, 2016 at 5:47 AM, Matthew Kerwin <[e-mail]>
wrote:
>>
>>
>> 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).
>

If service providers want to cover their butts, can't they add an "EU
cookie law"-like banner that says, "We'll also do this thing, which could
leak personal info this way. Click this X to opt out" and then not send the
alt-svc stuff? The onus is on them not to stalk us, after all.

At least that way alt-svc is no worse than cookies, even if it's no better.

>>
>> 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.
>

I don't understand the third point... The cert for the alt-svc wouldn't be
any different than if the URI hostname was a CNAME pointing at the alt-svc
address, which serves a cert with a SAN for the original URI hostname. Or
am I misunderstanding how you verify that the alt-svc is a valid origin for
the URI?

It's not like receiving an alt-svc frame/header causes the client to
redirect the current request (does it?) -- it comes into play on subsequent
requests. Since by the time you hit the alt-svc there's no "original URI"
connection, there's no "original URI chain" per se.

>
> 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.

I don't follow; however...

The bigger conflict as I see it is between speed and privacy. Spinning up a
TCP connection across the world is slow enough, adding TLS just makes it
that much worse -- if you can reuse an existing tube you can save all of
that lost time. The cost, then, is that the server at the far end of that
tube knows for sure that the client at the near end is the same client for
both requests down that tube, which it might not otherwise know. It doesn't
know that the client is a single UA (or a single human) though; it might be
a gateway/proxy of some sort.

So the choice we offer to users is: maybe announce that you're one person
across multiple requests vs. maybe watch cat gifs sooner. We already
provide a similar choice: maybe announce that you're one person across
multiple requests vs. be able to use online services the way they're
written across sessions. (I.e. incognito vs. not). "Incognito" means
"privacy", so why not include this under that?