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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 03 June 2015 22:44 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 CCC131B3006 for <ietf@ietfa.amsl.com>; Wed, 3 Jun 2015 15:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 r-hrH3ltxW3h for <ietf@ietfa.amsl.com>; Wed, 3 Jun 2015 15:44:12 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA181B3009 for <ietf@ietf.org>; Wed, 3 Jun 2015 15:44:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC517BF0B; Wed, 3 Jun 2015 23:44:10 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5dnvwDoYqw6; Wed, 3 Jun 2015 23:44:09 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8F98CBF06; Wed, 3 Jun 2015 23:44:09 +0100 (IST)
Message-ID: <556F8339.5030002@cs.tcd.ie>
Date: Wed, 03 Jun 2015 23:44:09 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Tony Hain <alh-ietf@tndh.net>, ietf@ietf.org
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com> <0ab501d09e37$f4098980$dc1c9c80$@tndh.net> <556F6083.4080801@cs.tcd.ie> <0adf01d09e40$cf957b00$6ec07100$@tndh.net>
In-Reply-To: <0adf01d09e40$cf957b00$6ec07100$@tndh.net>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/nAG8orPTRJ3YHqzkzslDUPx4nA4>
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: Wed, 03 Jun 2015 22:44:15 -0000


On 03/06/15 22:03, Tony Hain wrote:
> Stephen Farrell wrote:
> 
>> I would assert that the existence of the dprive WG is good evidence
>> that the IETF does not consider data-integrity as the only real
>> concern for public data.
> 
> And I would assert that it shows a group-think knee-jerk overreaction
> to threats that hypothetically could be applied in broader contexts
> than history documents. We are both free to express our own
> assertions.
> 

Disagreeing is of course fine but does not require that those
with whom one disagrees are stuck in a group-think knee-jerk
mixed metaphor;-)

Looking at the actual text of the statement though [1] I could
agree that the 3rd paragraph is maybe more justified on security
grounds, so maybe s/privacy/security&privacy/ would be better there.

That said, there is a real threat to privacy (cf. tempora) when it
is credible to assume that any of our traffic that transits undersea
cables is recorded, and traffic to the IETF is a part of that even
if it's quite unlikely, by itself, to be privacy sensitive.

(Someone else already pointed out that it'd be worth noting that
HTTPS isn't perfect in the face of traffic analysis, so adding
text on that would also make sense just so's we're clear that
we're not claiming that there's a panacea hereabouts, and is
worth a mention here too.)

S.

[1] https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere