Re: Alt-Svc Privacy Concerns
Phil Lello <phil@dunlop-lello.uk> Mon, 11 April 2016 11:46 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B459612EC5D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Apr 2016 04:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.916
X-Spam-Level:
X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dunlop-lello-uk.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkzyGq4_Lbc6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Apr 2016 04:46:02 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C4812E540 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 11 Apr 2016 04:46:01 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1apaDu-0005SE-0d for ietf-http-wg-dist@listhub.w3.org; Mon, 11 Apr 2016 11:41:42 +0000
Resent-Date: Mon, 11 Apr 2016 11:41:42 +0000
Resent-Message-Id: <E1apaDu-0005SE-0d@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <phil@dunlop-lello.uk>) id 1apaDp-0005Pu-6R for ietf-http-wg@listhub.w3.org; Mon, 11 Apr 2016 11:41:37 +0000
Received: from mail-lf0-f50.google.com ([209.85.215.50]) by lisa.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <phil@dunlop-lello.uk>) id 1apaDe-00054p-Vg for ietf-http-wg@w3.org; Mon, 11 Apr 2016 11:41:31 +0000
Received: by mail-lf0-f50.google.com with SMTP id c126so152653142lfb.2 for <ietf-http-wg@w3.org>; Mon, 11 Apr 2016 04:41:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunlop-lello-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=IQHiyw2L0pqI6gU6MmcLrrK6yarid2GhDSnhTu0NWUk=; b=uEJ8FTTH1EzJrXdFNViyd6woQzEcjZce/joU5elRjDZlAZalXOpRFfQ5hOsrVoPy/3 0hp555fhL7kucQdiZ+E3KqJPFgyNUzVLtohPTqebxnvuhVWUIWUowp6b8DckZAeusG/C J44MXq6yPSdp4th8i4I/vjWuhogSi1+heIt6M5bti19TGlInVXIHNph55DueaU3rbD1J GuY2jILWrEmIIDSXYWnetYUoTP49caWMJ11d1CFVb3N7p4qlH9cYz4DBZ8PEoX16VlYB Qu0dY5q9kfzqgKyi0Us0fZd9qXMzwTkb7stctQx7ULncab+9QdXnrTB9XOD0gGwrWwJZ xfmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=IQHiyw2L0pqI6gU6MmcLrrK6yarid2GhDSnhTu0NWUk=; b=aQfsLha3D8x7gHFYQhmqMN5C56eI9V8E7pNm2TnisRY198w4aLl4dWnF8hsu68eY0/ IuTPsFrVIPRzt5TQiKChnUvooshFi2CAf/ZE4SBPmcSPDyQt33NLgqqXg+K2Rmii908c BDDX0bZC5LghRDWXY9csnHSO1cHbp0Y+s1C0Uv79cI/zdkIT30hH3oR5G133HDYU9+Ac jodT+Viz9ijzKUOuDQp9wHtf0JboCnoKVcXFBO1j28Bf4YZMmEYaS1RumuIRzeFoCCXb /c97Z1RuCOChZZzueKLzFfGQMnHBJ1VSslj+uqgJLj0hzMeEz1gJ/vNmuCl9aCKGFqgr XLbA==
X-Gm-Message-State: AD7BkJIvk/7m6NGk+J1cxb3aVkU/TgfxRI0sqlCE9gVI3/qAJBKp1QlWitcUqjgv1/Wwlj+VZRbFWOL/QIziRUcU
MIME-Version: 1.0
X-Received: by 10.25.7.4 with SMTP id 4mr8324575lfh.147.1460374858707; Mon, 11 Apr 2016 04:40:58 -0700 (PDT)
Received: by 10.25.27.16 with HTTP; Mon, 11 Apr 2016 04:40:58 -0700 (PDT)
In-Reply-To: <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> <D633E3BB-A86D-4F04-B75B-A825B252CB07@mnot.net>
Date: Mon, 11 Apr 2016 12:40:58 +0100
Message-ID: <CAPofZaFqrqnB6Jdq1ic=ZsGrWrGOp8KQP=K3KmkYMJ10mukTFQ@mail.gmail.com>
From: Phil Lello <phil@dunlop-lello.uk>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a113ea9ceb1523f053034046d"
Received-SPF: none client-ip=209.85.215.50; envelope-from=phil@dunlop-lello.uk; helo=mail-lf0-f50.google.com
X-W3C-Hub-Spam-Status: No, score=-5.8
X-W3C-Hub-Spam-Report: AWL=-1.151, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1apaDe-00054p-Vg cae05cf2927b506b963f0eccf9735c44
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Alt-Svc Privacy Concerns
Archived-At: <http://www.w3.org/mid/CAPofZaFqrqnB6Jdq1ic=ZsGrWrGOp8KQP=K3KmkYMJ10mukTFQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31417
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
> 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. > Thanks, that's a good start; in an ideal world, I'd hope for a successor that included a bullet-point summary to help techies in non-technical organisations present a concise "industry standard" to decision makers. That said, I fully appreciate the complexities of obtaining consensus when balancing different cultural norms, commercial and consumer interests, and given geopolitics, it's a moving target. 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. > That's great news, I will certainly try to contribute to that effort - although, no doubt like many others, I'm already struggling to keep up with the volume of messages accross multiple technolgoy lists. > 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. > I'll mostly concede that point; it's the potential for subsequent aggregation on one connection under HTTP/2 that is the new challenge. However, I do think that there needs to be a recommendation for UI/UX behavior around here - I haven't got a good solution, since displaying two servers in the address bar would just add to clutter. Perhaps an info/warning indicator by the address bar would work, showing where subsequent requests would load from (but not hugely effective for on-page assets, unless these are pushed from origin). I think aggregation concerns are likely to become a bigger issue given the trends towards cloud computing and CDNs. 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. > > 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/>. > > Indeed, it's an ongoing battle. > 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? > > I think the process generally works quite well; the unfortunate timing is more of a time issue my end, to be honest - my involvement on IETF lists at present is part of a vested professional interest rather than part of my day job - although I'm actively seeking to change that. I doubt I'm the only participant with that issue. The process that could potentially do with refinement is encourage general-public review of the privacy aspects of consumer technologies (HTTP being the most obvious, possibly mail/news protocols, others more debatable); that said, it would appear to be a significant change of scope for the IETF, and present a lot of new challenges, so might be best left to a partner organisation. > > > 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. > > -- > Mark Nottingham https://www.mnot.net/ > >
- Alt-Svc Privacy Concerns Phil Lello
- Re: Alt-Svc Privacy Concerns Martin Thomson
- Re: Alt-Svc Privacy Concerns Phil Lello
- Re: Alt-Svc Privacy Concerns Ryan Hamilton
- Re: Alt-Svc Privacy Concerns Matthew Kerwin
- Re: Alt-Svc Privacy Concerns Phil Lello
- Re: Alt-Svc Privacy Concerns Phil Lello
- Re: Alt-Svc Privacy Concerns Matthew Kerwin
- Re: Alt-Svc Privacy Concerns Phil Lello
- Re: Alt-Svc Privacy Concerns Erik Nygren
- Re: Alt-Svc Privacy Concerns Phil Lello
- Re: Alt-Svc Privacy Concerns Mark Nottingham
- Re: Alt-Svc Privacy Concerns Phil Lello