Resent-Date: Mon, 11 Apr 2016 01:06:53 +0000
Resent-Message-Id: <E1apQJZ-0007Ge-Qq@frink.w3.org>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAPofZaGshLKNEWp6qTszDwcXOATUYRnkkNJRd2Z=avo1rXkLTw@mail.gmail.com>
Date: Mon, 11 Apr 2016 11:06:17 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D633E3BB-A86D-4F04-B75B-A825B252CB07@mnot.net>
References: <CAPofZaEG3gm79CznQuB8RdZb6hXYV7ZiBNTwYj=autVP1=_Cng@mail.gmail.com>
 <CABkgnnUr4bif_sLGYWq2CWEcZFzucjapjghF9E4HjnTvVGGfXw@mail.gmail.com>
 <CAPofZaEzobDStP9Pm2kSBZOMmmziu5N8bkALvb++ETdnva0K3A@mail.gmail.com>
 <CACweHNBoAOX4mWjyeAw7QWmsdb=zGVkx4-t2ftpcLzZg6k1sGg@mail.gmail.com>
 <CAPofZaHQFtyW06-R44O7YzuDjU5v2Ekdc+1o8TvVkdVgrctegQ@mail.gmail.com>
 <CACweHNBeLa4-UVJmPiSaE+BiOWFnqTHkJe6qkZa2CmkNoTXL3w@mail.gmail.com>
 <CAPofZaGshLKNEWp6qTszDwcXOATUYRnkkNJRd2Z=avo1rXkLTw@mail.gmail.com>
To: Phil Lello <phil@dunlop-lello.uk>
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net;
 helo=mxout-07.mxes.net
Subject: Re: Alt-Svc Privacy Concerns
Archived-At: <http://www.w3.org/mid/D633E3BB-A86D-4F04-B75B-A825B252CB07@mnot.net>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

Hi Phil,

> On 11 Apr 2016, at 2:19 AM, Phil Lello <phil@dunlop-lello.uk> wrote:
>=20
> Hi Mark,
>=20
> 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.

It's actually because I was flying home from Buenos Aires, and dealing =
with jetlag (still ongoing).

I think the document you're looking for is =
<https://tools.ietf.org/html/rfc6973>. It's only Informational at the =
moment, but it is a product of the IAB, and in time it (or its =
successor) might become "more official," so it's the closest we have to =
a policy statement.

There's also an active discussion in the HRPC - <https://irtf.org/hrpc>, =
who are trying to figure out how to apply human rights considerations to =
protocol design.

Regarding Alt-Svc: people are comparing its privacy properties to =
cookies, but I think a more apt comparison would be DNS CNAMEs. The =
scenario you describe is already quite possible and easy to implement on =
the Internet, and Alt-Svc doesn't make it significantly easier or more =
successful, as far as we saw; it just shifts the redirection mechanism =
to another layer.=20

Even in a world where both of these were not possible (and that's a =
stretch), colluding servers could share information about you in a =
back-end channel, using a variety of techniques to identify you as the =
user.=20

That's not to dismiss the concerns you have; it's just that tracking on =
the Web is very difficult to prevent. The W3C TAG talks about this a bit =
here: <https://www.w3.org/2001/tag/doc/unsanctioned-tracking/>.=20

One final thing - it's a pity that we're getting this feedback from you =
now, after the document is published. While we can, of course, revise it =
if need be, it's much more effective to have wide review before =
publication. Is there anything we could have done to get it earlier?

Cheers,



> 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).
> >
>=20
> 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.
>=20
> At least that way alt-svc is no worse than cookies, even if it's no =
better.
>=20
> 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.
> >
>=20
> 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?
>=20
> 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.
>=20
>  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.
>=20
> I don't follow; however...
>=20
> 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,
>=20
> Yes, and as a technical solution, this is absolutely fine, however....=20=

> 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.
>=20
> 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).=20
> 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?
>=20
> 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.".
>=20
> 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.
>=20
> 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.

--
Mark Nottingham   https://www.mnot.net/