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

Christian Huitema <> Thu, 04 June 2015 17:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D36441A1B83 for <>; Thu, 4 Jun 2015 10:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PZrbLqks8LRj for <>; Thu, 4 Jun 2015 10:18:17 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6A8F1A1B73 for <>; Thu, 4 Jun 2015 10:18:16 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 4 Jun 2015 17:17:57 +0000
Received: from ([]) by ([]) with mapi id 15.01.0172.012; Thu, 4 Jun 2015 17:17:57 +0000
From: Christian Huitema <>
To: Joe Hildebrand <>, "" <>
Subject: RE: Proposed Statement on "HTTPS everywhere for the IETF"
Thread-Topic: Proposed Statement on "HTTPS everywhere for the IETF"
Date: Thu, 4 Jun 2015 17:17:57 +0000
Message-ID: <>
References: <> <0ab501d09e37$f4098980$dc1c9c80$> <> <0adf01d09e40$cf957b00$6ec07100$> <> <0b3901d09e73$7dad4740$7907d5c0$> <> <0b9001d09edc$63df32b0$2b9d9810$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
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: <>
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;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


-- Christian Huitema