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

"Tony Hain" <alh-ietf@tndh.net> Thu, 04 June 2015 17:20 UTC

Return-Path: <alh-ietf@tndh.net>
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 E6A181A1BD4 for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2015 10:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.098
X-Spam-Level:
X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 YsH_AMKGw8oz for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2015 10:20:51 -0700 (PDT)
Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1AD1A1B64 for <ietf@ietf.org>; Thu, 4 Jun 2015 10:20:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=IGJFuJsFNKAZqYRqFyNAoWp8jdjiPaL6fOwF9OboqEY=; b=Ap3KvCNpbI5uIFdpfT9FIjnFNRv4CyDzWNdbkj2knH1D4jiKEbcGTaPe4BQZRGIdcu0HLaWezSalIG+I0kGvgd34MZ4OBq1E9bFRaDfeIGRWTFIXP5b5udz4+RjpC2HX3OsUpu0PBmoUfvleR4fH8yOeo5C4dhKPbnHpd9K+njNAQShu;
Received: from express.tndh.local ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <alh-ietf@tndh.net>) id 1Z0Yoo-000NGR-N6; Thu, 04 Jun 2015 10:20:50 -0700
From: Tony Hain <alh-ietf@tndh.net>
To: 'Joe Hildebrand' <hildjj@cursive.net>, ietf@ietf.org
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>
Date: Thu, 04 Jun 2015 10:20:40 -0700
Message-ID: <0bc201d09eea$c84782d0$58d68870$@tndh.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEOzNU1RqxCT3Y5GM1VnUp3WH8IOAILo+5xA0TRpzwDJpYdMQLGSIezAiNwF/8CAIbo/wNjQmVyATM5/o2egHgKIA==
Content-Language: en-us
X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a
X-SA-Exim-Mail-From: alh-ietf@tndh.net
Subject: RE: Proposed Statement on "HTTPS everywhere for the IETF"
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on express.tndh.net)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/JKBwox7nrpxE00MpZn6fofT2y4Q>
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:20:52 -0000

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.

The set of possible requests is inherently public information. Pairing a
request length with the possible set of return lengths seriously reduces the
set, and that is before you factor in who is being watched and what they
might be looking for.

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

On  the contrary, it only further exposes how much of an irrational
knee-jerk this effort is. If you have to define something new, then get it
deployed, it is not ready for prime-time and therefore this effort is
premature at best. A more rational thing that could be part of the tooling
effort without much delay would be to define a random COMMENT padding which
would vary the length of the returned stream. 

Again, I am not objecting to encrypting the content. I am concerned that the
IESG is "out of scope" by making a political statement, particularly when it
is not necessary. It is completely rational and within scope for the IESG to
be concerned about data-integrity, and stating they are turning on https by
default to accomplish that. There is no need for the word 'privacy' to occur
within the statement, and is blatantly misleading without taking more steps
than are being outlined here.

Tony