Re: Alt-Svc Privacy Concerns

Hi Mark,

As Working Group Chair, could you respond to at least the BCP/policy
statement request below? I fully appreciate your silence thus far is most
likely because it's a weekend, and not because of a lack of interest.

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

> On 10/04/2016 9:06 PM, "Phil Lello" <phil@dunlop-lello.uk> wrote:
> >
> > On Sun, Apr 10, 2016 at 5:47 AM, Matthew Kerwin <matthew@kerwin.net.au>
> 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.
>
This requires documenting in an RFC. The service provider could be unaware
of tracking if a rogue CDN operator was aggregating multiple sites via a
common Host and is using Alt-Used to choose the content. I will try to find
time to look into Firefox and Chromium source to see if/how they currently
handle http Alt-Svc pointing to https on another hostname - a version of
Alt-Svc is already in the wild, but may be limited to same-host (as in the
output of curl -I https://www.youtube.com)

> >>
> >> 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.
>
 I misunderstood the specification here, this is loosely covered by RFC7838
s2.1 "For example, if the origin's host is "www.example.com" and an
alternative is offered on "other.example.com" with the "h2" protocol, and
the certificate offered is valid for "www.example.com", the client can use
the alternative.". This has, however, been left up to the client, and is
not a MUST - the stipulation is "Clients MUST have reasonable assurances
that the alternative service is under control of and valid for the whole
origin."

> >
> > 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,
>
Yes, and as a technical solution, this is absolutely fine, however....

> 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.
>
It's pretty unlikely to be a gateway/proxy though, given that TLS is
intended to be end-to-end, and there are active efforts to defeat the use
of a proxy with HTTPS (RFCs 7469 and 7671, for example).

> 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?
>
Except it's not really being offered to users; it's being offered to
browser vendors competing to produce, amongst other things, the fastest
browser. Guidance on the wording is important, because it would be trivial
to influence users to consent to "allow aggregation to make my experience
faster" and downplay "allow service providers and aggregators to track my
activity accross multiple sites" - indeed, RFC 7838 already downplays the
privacy issue with "By using unique names, servers could conceivably track
client requests. Such tracking could follow users across multiple networks,
when the "persist" flag is used.".

I really think there needs to be a BCP created that describes the IETFs
official position on privacy - it's already entered the social
change/policy arena with at least BCP188 in May 2014, if not earlier. I'd
be a lot more comfortable if as well as seeking to restrict monitoring by
parents, schools, corporate administrators, network operators, and law
enforcement agencies it sought to restrict monitoring by service providers
and agregators.

Would the Working Group Chair care to weigh in on this? I appreciate policy
statements probably need to come from the Area Director and the Internet
Engineering Steering Group, so acknowledgement that it's under discussion
would suffice.