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

"Joe Hildebrand" <hildjj@cursive.net> Thu, 04 June 2015 16:54 UTC

Return-Path: <hildjj@cursive.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 0B2B41A001A for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2015 09:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=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 2EhlYJ-EVwn8 for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2015 09:54:05 -0700 (PDT)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B831A0015 for <ietf@ietf.org>; Thu, 4 Jun 2015 09:54:05 -0700 (PDT)
Received: by pdbnf5 with SMTP id nf5so34646198pdb.2 for <ietf@ietf.org>; Thu, 04 Jun 2015 09:54:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cursive.net; s=google; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=byqQBFRCYBlTzUqx64rMe5fVep1MaBn5ZOeP80fNTyM=; b=VR0O8BCvim05gVFRBD6024y73dkKo8wJjgf0d8l+gOn9tm5nV74DVfY1vWEkPRNyYh GirXbCzGgXAbXvvuFij6JDrYPykCsAHuMzj2/7JFo+6x/RKSdYg7XKhqXvSUXkr2euwX LqIRamn7LEPkefA/7uNAINCgNQGC2z6N6cdX4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=byqQBFRCYBlTzUqx64rMe5fVep1MaBn5ZOeP80fNTyM=; b=EUru0srx2PF3hp9DxmQbDPpdrBotxwWyEDERuN00Yk8Uwh60hNlmH1K4Mn0lL+VWZU 05eAlgx16zKoPuaqVt4v6f6Qsr9RESn59WHGgwXqxqnnBunPYfOtzc1+TYYeA0n1F2mm v93vX6c6oYU5cMjRhFNwen8KMSOhX8wO6FfNpCiCx16gY0Izm00Utunxp/mR1k3kkIsk Tp3l/+mXzMQLWPC2ZSLDWS8NM/OnXL5Ekq6VgD07EmFb3iIh8iA/lt8WLW6mEmji0K7L u7YM0I3nQFhNtWuH/XWE/DXKUGQrGvIHfQDzC3L60E9EZTbPUpS0W41Fxm/iqIZ6a3Xb 2jeQ==
X-Gm-Message-State: ALoCoQmbkU431tuOkT/Q8NAEbUS2LkZnV1uC31FZ+2/OdFFOHFADHs2H3l5m9OIGra35d9nqAvTc
X-Received: by 10.68.221.70 with SMTP id qc6mr28720413pbc.76.1433436844720; Thu, 04 Jun 2015 09:54:04 -0700 (PDT)
Received: from [10.24.203.138] ([128.107.241.183]) by mx.google.com with ESMTPSA id si7sm4279225pbc.54.2015.06.04.09.54.02 for <ietf@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Jun 2015 09:54:03 -0700 (PDT)
From: "Joe Hildebrand" <hildjj@cursive.net>
To: ietf@ietf.org
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
Date: Thu, 04 Jun 2015 10:53:56 -0600
Message-ID: <DA60EE0C-BC66-44E0-A00C-C9A96BA36DC6@cursive.net>
In-Reply-To: <0b9001d09edc$63df32b0$2b9d9810$@tndh.net>
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>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate Trial (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/gqls_Q5S_y_LVWn5kV9zhYd2WEg>
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 16:54:06 -0000

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.

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.

-- 
Joe Hildebrand