RE: Proposed Statement on "HTTPS everywhere for the IETF"

Christian Huitema <huitema@microsoft.com> Thu, 04 June 2015 17:18 UTC

Return-Path: <huitema@microsoft.com>
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 D36441A1B83 for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2015 10:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PZrbLqks8LRj for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2015 10:18:17 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A8F1A1B73 for <ietf@ietf.org>; Thu, 4 Jun 2015 10:18:16 -0700 (PDT)
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 4 Jun 2015 17:17:57 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0172.012; Thu, 4 Jun 2015 17:17:57 +0000
From: Christian Huitema <huitema@microsoft.com>
To: Joe Hildebrand <hildjj@cursive.net>, "ietf@ietf.org" <ietf@ietf.org>
Subject: RE: Proposed Statement on "HTTPS everywhere for the IETF"
Thread-Topic: Proposed Statement on "HTTPS everywhere for the IETF"
Thread-Index: AQEOzNU1nxYpgJ/fxUq9klJ8uO9a9p8e0ySAgAAHbICAAA1kgIAAG/2AgABJXoCAAAW8AIAAzBGAgAAVUACAAAUTQA==
Date: Thu, 4 Jun 2015 17:17:57 +0000
Message-ID: <DM2PR0301MB065530F5C0937001D3055579A8B30@DM2PR0301MB0655.namprd03.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>
In-Reply-To: <DA60EE0C-BC66-44E0-A00C-C9A96BA36DC6@cursive.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com;
x-originating-ip: [2001:4898:80e0:ee43::3]
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 3:E9ToV5fXhRVOqwHPW1DMyX6X4ZmmLg/wsQPe48XSMygIZk5fgHqvLYmj2FPYygOfpnbWysezzB/Vc9nbKRzHMhZpq0AGoySG6bFVKZXBvAlWV6blGJTMp1c5ZLc5jOQ2ObZJwlEM+rhiJ+d8FevyVQ==; 10:OsgbFQBHWNiWVyiTm0dg/tqN0eplDWNCqfxWjNaj20avQWArF7UGzWXTyG4gkx47jdqZx2e9wHpTeTBkbHXzcLRq/d1Wz4OC6aCVtMQ7tdg=; 6:61eXEXDDzXgkj9MDZB+XuV9vqtYo7EHoHTTslu6HzXL3g8bycuAn8GImzUnxqHzk
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654;
x-microsoft-antispam-prvs: <DM2PR0301MB06544B636F2221CA9512D4C5A8B30@DM2PR0301MB0654.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(520003)(3002001); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654;
x-forefront-prvs: 0597911EE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(51704005)(24454002)(107886002)(101416001)(5001860100001)(5001960100002)(46102003)(122556002)(68736005)(86612001)(5001770100001)(74316001)(5002640100001)(2950100001)(4001540100001)(189998001)(2900100001)(92566002)(87936001)(40100003)(102836002)(62966003)(77096005)(86362001)(97736004)(2501003)(64706001)(77156002)(81156007)(2656002)(76576001)(99286002)(106356001)(106116001)(33656002)(76176999)(105586002)(50986999)(54356999)(93886004)(5001830100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2015 17:17:57.3841 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/pePhVnESM_GvY4toIVbuh2n2jg0>
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: Thu, 04 Jun 2015 17:18:23 -0000

On Thursday, June 4, 2015 9:54 AM, Joe Hildebrand 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.

What Joe says. Encrypting data is just one component of providing privacy, but it is a very useful component. Clear text headers leak various kinds of "meta-data," which facilitate correlation and traffic analysis. For example, if people access the IETF from a public Wi-Fi and manages to leak meta-data on that hot spot, their traffic will be very hard to analyze and correlate with their identity. Of course, that takes more than just encrypting the end-to-end application traffic, but encryption is definitely a key component of the solution.

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

Yes.

-- Christian Huitema