Re: Proposed Statement on "HTTPS everywhere for the IETF"
<l.wood@surrey.ac.uk> Fri, 05 June 2015 11:03 UTC
Return-Path: <l.wood@surrey.ac.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ED11B2EA2 for <ietf@ietfa.amsl.com>; Fri, 5 Jun 2015 04:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 mqbJbUuHpEo1 for <ietf@ietfa.amsl.com>; Fri, 5 Jun 2015 04:03:39 -0700 (PDT)
Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37CA91B2EA0 for <ietf@ietf.org>; Fri, 5 Jun 2015 04:03:39 -0700 (PDT)
Received: from [193.109.255.147] by server-9.bemta-14.messagelabs.com id 6F/ED-03371-90281755; Fri, 05 Jun 2015 11:03:37 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-16.tower-72.messagelabs.com!1433502217!14712747!1
X-Originating-IP: [131.227.200.43]
X-StarScan-Received:
X-StarScan-Version: 6.13.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24081 invoked from network); 5 Jun 2015 11:03:37 -0000
Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-16.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 5 Jun 2015 11:03:37 -0000
Received: from EXHY012V.surrey.ac.uk (131.227.201.103) by EXHT022P.surrey.ac.uk (131.227.200.43) with Microsoft SMTP Server (TLS) id 8.3.342.0; Fri, 5 Jun 2015 12:03:36 +0100
Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY012v.surrey.ac.uk (131.227.201.103) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 5 Jun 2015 12:03:36 +0100
Received: from DB4PR06MB457.eurprd06.prod.outlook.com (10.141.238.15) by DB4PR06MB460.eurprd06.prod.outlook.com (10.141.238.24) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 5 Jun 2015 11:03:36 +0000
Received: from DB4PR06MB457.eurprd06.prod.outlook.com ([10.141.238.15]) by DB4PR06MB457.eurprd06.prod.outlook.com ([10.141.238.15]) with mapi id 15.01.0172.012; Fri, 5 Jun 2015 11:03:35 +0000
From: l.wood@surrey.ac.uk
To: fielding@gbiv.com, hildjj@cursive.net
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
Thread-Topic: Proposed Statement on "HTTPS everywhere for the IETF"
Thread-Index: AQHQnIpN6VdBLrz+YkuVYdvl9F3Ogp2bNtIAgAAEU4CAAA1lgIAAG/yAgABJX4CAAAW7AIAAzBKAgAAVUACAAEQGAIAA7Bh+
Date: Fri, 05 Jun 2015 11:03:35 +0000
Message-ID: <DB4PR06MB457855A79A16402B0F4F432ADB20@DB4PR06MB457.eurprd06.prod.outlook.com>
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com> <0ab501d09e37$f4098980$dc1c9c80$@tndh.net> <556F6083.4080801@cs.tcd.ie> <0adf01d09e40$cf957b00$6ec07100$@tndh.net> <556F8339.5030002@cs.tcd.ie> <0b3901d09e73$7dad4740$7907d5c0$@tndh.net> <556FC594.1080900@gmail.com> <0b9001d09edc$63df32b0$2b9d9810$@tndh.net> <DA60EE0C-BC66-44E0-A00C-C9A96BA36DC6@cursive.net>, <1C116522-648B-4C69-91BC-C56062FFB166@gbiv.com>
In-Reply-To: <1C116522-648B-4C69-91BC-C56062FFB166@gbiv.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [124.168.152.71]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB460;
x-microsoft-antispam-prvs: <DB4PR06MB460EDE5F0595ECD940F6720ADB20@DB4PR06MB460.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:DB4PR06MB460; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB460;
x-forefront-prvs: 05986C03E0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(24454002)(74316001)(46102003)(74482002)(33656002)(5002640100001)(54356999)(50986999)(76176999)(86362001)(66066001)(561944003)(76576001)(189998001)(93886004)(87936001)(19580395003)(19580405001)(2656002)(102836002)(92566002)(5001770100001)(77096005)(2950100001)(40100003)(77156002)(62966003)(122556002)(106116001)(5001960100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB460; H:DB4PR06MB457.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2015 11:03:35.7215 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6b902693-1074-40aa-9e21-d89446a2ebb5
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB460
X-OrganizationHeadersPreserved: DB4PR06MB460.eurprd06.prod.outlook.com
X-CrossPremisesHeadersFiltered: EXHY012v.surrey.ac.uk
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/p5C_bze8jFNHOyLI-ZKqz37OaGs>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2015 11:03:41 -0000
> However, I agree with Tony's assessment: > most of the text is nothing more than a > pompous political statement, much like the sham of > "consensus" that was contrived at the Vancouver IETF. +1 L. ________________________________________ From: ietf <ietf-bounces@ietf.org> on behalf of Roy T. Fielding <fielding@gbiv.com> Sent: Friday, 5 June 2015 6:57:24 AM To: Joe Hildebrand Cc: ietf@ietf.org Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF" > On Jun 4, 2015, at 9:53 AM, Joe Hildebrand <hildjj@cursive.net> wrote: > > On 4 Jun 2015, at 9:37, Tony Hain wrote: > >> My overall concern here is that statements like this undermine the integrity of the organization. I understand people wanting to improve overall privacy, but this step does not do that in any meaningful way. > > Encrypting the channel does provide some small amount of privacy for the *request*, which is not public information. Browser capabilities, cookies, etc. benefit from not being easily-correlated with other information. That is message confidentiality, not privacy. Almost all of the privacy bits (as in, which person is doing what and where) are revealed outside of the message. > It would be interesting to define an HTTP header of "Padding" into which the client would put some random noise to pad the request to a well-known size, in order to make traffic analysis of the request slightly more difficult. This is the sort of thing that comes up when we talk about doing more encryption for the IETF's data, which shows the IESG's suggested approach to be completely rational. Browsers don't send singular messages containing anonymous information. They send a complex sequence of messages to multiple parties with an interaction pattern and communication state. The more complex and encrypted the communication, the more uncommon state and direct communication is required, which makes it easier to track a person across multiple requests until the user's identity is revealed. Furthermore, with TLS in place, it becomes easy and commonplace to send stored authentication credentials in those requests, without visibility, and without the ability to easily reset those credentials (unlike in-the-clear cookies). Padding has very little effect. It isn't just the message sizes that change -- it is all of the behavior that changes, and all of the references to that behavior in subsequent requests, and the effects of those changes on both the server and the client. TLS does not provide privacy. What it does is disable anonymous access to ensure authority. It changes access patterns away from decentralized caching to more centralized authority control. That is the opposite of privacy. TLS is desirable for access to account-based services wherein anonymity is not a concern (and usually not even allowed). TLS is NOT desirable for access to public information, except in that it provides an ephemeral form of message integrity that is a weak replacement for content integrity. If the IETF wants to improve privacy, it should work on protocols that provide anonymous access to signed artifacts (authentication of the content, not the connection) that is independent of the user's access mechanism. I have no objection to the IESG proposal to provide information *also* via https. It would be better to provide content signatures and encourage mirroring, just to be a good example, but I don't expect eggs to show up before chickens. However, I agree with Tony's assessment: most of the text is nothing more than a pompous political statement, much like the sham of "consensus" that was contrived at the Vancouver IETF. TLS everywhere is great for large companies with a financial stake in Internet centralization. It is even better for those providing identity services and TLS-outsourcing via CDNs. It's a shame that the IETF has been abused in this way to promote a campaign that will effectively end anonymous access, under the guise of promoting privacy. ....Roy
- Re: Proposed Statement on "HTTPS everywhere for t… Richard Barnes
- Re: Proposed Statement on "HTTPS everywhere for t… Bob Hinden
- Re: Proposed Statement on "HTTPS everywhere for t… Brian E Carpenter
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach
- Re: Proposed Statement on "HTTPS everywhere for t… Harald Alvestrand
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Phillip Hallam-Baker
- Re: Proposed Statement on "HTTPS everywhere for t… Nico Williams
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach (Syndicat.com)
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach (Syndicat.com)
- Re: Proposed Statement on "HTTPS everywhere for t… Paul Wouters
- Re: Proposed Statement on "HTTPS everywhere for t… Roland Dobbins
- Re: Proposed Statement on "HTTPS everywhere for t… Roland Dobbins
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Roland Dobbins
- Re: Proposed Statement on "HTTPS everywhere for t… Nico Williams
- Re: Proposed Statement on "HTTPS everywhere for t… Mark Baugher (mbaugher)
- Where are the places that block encrypted traffic? Sam Hartman
- Re: Proposed Statement on "HTTPS everywhere for t… S Moonesamy
- Re: Proposed Statement on "HTTPS everywhere for t… John Levine
- Re: Proposed Statement on "HTTPS everywhere for t… Masataka Ohta
- Re: Proposed Statement on "HTTPS everywhere for t… Eliot Lear
- Re: Proposed Statement on "HTTPS everywhere for t… Xiaoyin Liu
- Re: Where are the places that block encrypted tra… Patrik Fältström
- Re: Proposed Statement on "HTTPS everywhere for t… Eliot Lear
- Re: Proposed Statement on "HTTPS everywhere for t… Harald Alvestrand
- Re: Proposed Statement on "HTTPS everywhere for t… Jari Arkko
- Re: Proposed Statement on "HTTPS everywhere for t… Roland Dobbins
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach (Syndicat.com)
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach
- Re: Where are the places that block encrypted tra… Niels Dettenbach
- Re: Proposed Statement on "HTTPS everywhere for t… Mark Nottingham
- Re: Proposed Statement on "HTTPS everywhere for t… Stewart Bryant
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Jari Arkko
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… l.wood
- Re: Proposed Statement on "HTTPS everywhere for t… Ted Lemon
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Ted Lemon
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Ted Lemon
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Richard Barnes
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Brian E Carpenter
- Re: Proposed Statement on "HTTPS everywhere for t… Richard Barnes
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Richard Barnes
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Where are the places that block encrypted tra… Mark Andrews
- Re: Where are the places that block encrypted tra… Sam Hartman
- Re: Proposed Statement on "HTTPS everywhere for t… Jari Arkko
- Re: Proposed Statement on "HTTPS everywhere for t… Xiaoyin Liu
- Re: Proposed Statement on "HTTPS everywhere for t… Stewart Bryant
- Re: Proposed Statement on "HTTPS everywhere for t… t.p.
- Re: Proposed Statement on "HTTPS everywhere for t… t.p.
- Re: Where are the places that block encrypted tra… Tim Bray
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Where are the places that block encrypted tra… Warren Kumari
- Re: Proposed Statement on "HTTPS everywhere for t… Cullen Jennings (fluffy)
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- RE: Proposed Statement on "HTTPS everywhere for t… Tony Hain
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Cullen Jennings (fluffy)
- Re: Proposed Statement on "HTTPS everywhere for t… John C Klensin
- RE: Proposed Statement on "HTTPS everywhere for t… Tony Hain
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell
- Re: Proposed Statement on "HTTPS everywhere for t… John C Klensin
- RE: Proposed Statement on "HTTPS everywhere for t… Tony Hain
- Re: Proposed Statement on "HTTPS everywhere for t… Brian E Carpenter
- Re: Proposed Statement on "HTTPS everywhere for t… Yoav Nir
- RE: Proposed Statement on "HTTPS everywhere for t… Tony Hain
- Re: Proposed Statement on "HTTPS everywhere for t… Nico Williams
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Hildebrand
- RE: Proposed Statement on "HTTPS everywhere for t… Christian Huitema
- RE: Proposed Statement on "HTTPS everywhere for t… Tony Hain
- Re: Proposed Statement on "HTTPS everywhere for t… Ted Lemon
- Re: Proposed Statement on "HTTPS everywhere for t… Ted Lemon
- Re: Proposed Statement on "HTTPS everywhere for t… Joe Touch
- Re: Proposed Statement on "HTTPS everywhere for t… Benson Schliesser
- Re: Proposed Statement on "HTTPS everywhere for t… Nico Williams
- Re: Proposed Statement on "HTTPS everywhere for t… Roy T. Fielding
- Re: Proposed Statement on "HTTPS everywhere for t… Niels Dettenbach
- Re: Proposed Statement on "HTTPS everywhere for t… Mark Nottingham
- Re: Proposed Statement on "HTTPS everywhere for t… l.wood
- Re: Proposed Statement on "HTTPS everywhere for t… Hector Santos
- Re: Proposed Statement on "HTTPS everywhere for t… Xiaoyin Liu
- Re: Proposed Statement on "HTTPS everywhere for t… Hector Santos
- Re: Proposed Statement on "HTTPS everywhere for t… Hector Santos
- Re: Proposed Statement on "HTTPS everywhere for t… Roy T. Fielding
- Re: Proposed Statement on "HTTPS everywhere for t… Mark Nottingham
- Re: Proposed Statement on "HTTPS everywhere for t… Roy T. Fielding
- Re: Proposed Statement on "HTTPS everywhere for t… Stephen Farrell