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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 04 June 2015 03:27 UTC

Return-Path: <brian.e.carpenter@gmail.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 826F81B336C for <ietf@ietfa.amsl.com>; Wed, 3 Jun 2015 20:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 i82SsuzKfgP9 for <ietf@ietfa.amsl.com>; Wed, 3 Jun 2015 20:27:16 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 0725F1B336A for <ietf@ietf.org>; Wed, 3 Jun 2015 20:27:16 -0700 (PDT)
Received: by padjw17 with SMTP id jw17so20160224pad.2 for <ietf@ietf.org>; Wed, 03 Jun 2015 20:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=A2xgTbK8WUnzku04p9Ofh/j4lT8OLPTwDzSzazVeLII=; b=m2mWxh8/0X36J8/s0pxddMpLu+7pRMvMjWiP+xalYpZzLiOuuOmw9A7ccHQ4hQu9LP xA7aE1Wwns3vb6ujsBXBt3p1NnxPeDTkaDleqkfBmdeVPfso+qdzRn9jhVF4l+Swba8G QzXnqz/49QVeUtI8PdJC2A2qH6mxpus88SPwGaPlPW9u1JUrHQsoleDBanIgW1+gkRSA bIGK9bGK91yvwlX5rn8LjCVbC522MPl5H6vVA4OAgkWi2nG7cfBzD/sHaoIWMFz0ioOg CNZlHhOlsyFvFDxYnApori+L+gp+e8uQpVYrUP2gFefF0SL8rkrX9Zz63MhMucTUkXVj 7XpA==
X-Received: by 10.70.33.102 with SMTP id q6mr63922869pdi.37.1433388435590; Wed, 03 Jun 2015 20:27:15 -0700 (PDT)
Received: from ?IPv6:2406:e007:4366:1:28cc:dc4c:9703:6781? ([2406:e007:4366:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id fk10sm2172908pab.18.2015.06.03.20.27.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2015 20:27:14 -0700 (PDT)
Message-ID: <556FC594.1080900@gmail.com>
Date: Thu, 04 Jun 2015 15:27:16 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Tony Hain <alh-ietf@tndh.net>, 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>, 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> <556F8339.5030002@cs.tcd.ie> <0b3901d09e73$7dad4740$7907d5c0$@tndh.net>
In-Reply-To: <0b3901d09e73$7dad4740$7907d5c0$@tndh.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/mpLQ10lHTWGZK5R47aBW6xzvS_E>
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 03:27:17 -0000

Hi Tony,
On 04/06/2015 15:06, Tony Hain wrote:
> Stephen Farrell wrote:
>> 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.
> 
> No, more below.
> 
>>
>> 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.
> 
> I never argued that there is not a general threat to privacy due to recording, just that it does not apply here. My point was that the IETF does not have a general technical REQUIREMENT for privacy. There are many that WANT privacy in everything they do, but that does not equate to a real requirement for the public content of an open organization. Substituting security&pirvacy only makes a bad choice of words worse. The IETF has no business case for either, and if there was a case something would have been done about it long before now. 

It isn't the content that is private, of course. However, if there are IETF
participants who require a degree of privacy about their use of IETF public
information, it is entirely reasonable for the IETF to support that with a
straightforward measure like HTTPS. As has been pointed out already, that
is insufficient to provide a high degree of privacy.

Try "...the act of accessing public information required for routine tasks
can be privacy sensitive *on the user's side*..."

I don't see anything political about that. It's factual.

    Brian