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

Brian E Carpenter <> Thu, 04 June 2015 03:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 826F81B336C for <>; Wed, 3 Jun 2015 20:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i82SsuzKfgP9 for <>; Wed, 3 Jun 2015 20:27:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0725F1B336A for <>; Wed, 3 Jun 2015 20:27:16 -0700 (PDT)
Received: by padjw17 with SMTP id jw17so20160224pad.2 for <>; Wed, 03 Jun 2015 20:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 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 with ESMTPSA id fk10sm2172908pab.18.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2015 20:27:14 -0700 (PDT)
Message-ID: <>
Date: Thu, 04 Jun 2015 15:27:16 +1200
From: Brian E Carpenter <>
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 <>, 'Stephen Farrell' <>,
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
References: <> <0ab501d09e37$f4098980$dc1c9c80$> <> <0adf01d09e40$cf957b00$6ec07100$> <> <0b3901d09e73$7dad4740$7907d5c0$>
In-Reply-To: <0b3901d09e73$7dad4740$7907d5c0$>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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 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.