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

"Tony Hain" <> Thu, 04 June 2015 03:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D54C1B32EF for <>; Wed, 3 Jun 2015 20:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.098
X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_20=-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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BzecWIiLYNqt for <>; Wed, 3 Jun 2015 20:07:01 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 078AE1B32D5 for <>; Wed, 3 Jun 2015 20:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=dzxQubp5CRsakGNdf+z0SyFJTWVf3oERvqrfr51+fII=; b=AxoHHn/h/Wo5B4Y9JXvouRYYT3SSJSs2C8DeAledcj6n+MmwALYBRcp/nJlvF7/ww5FhYbxjURCoR156WHVN4SMG1mjqYmSUKxAJGXaHPpF8jVBvguh+Mp/yk/7tOCWPu609ZY37P+/8bZqb9FfC9orzDmQoG8lJ7U7bBf4Us/Z8vjHF;
Received: from express.tndh.local ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <>) id 1Z0LUS-0009Hv-EO; Wed, 03 Jun 2015 20:06:56 -0700
From: "Tony Hain" <>
To: "'Stephen Farrell'" <>, <>
References: <> <0ab501d09e37$f4098980$dc1c9c80$> <> <0adf01d09e40$cf957b00$6ec07100$> <>
In-Reply-To: <>
Date: Wed, 3 Jun 2015 20:06:45 -0700
Message-ID: <0b3901d09e73$7dad4740$7907d5c0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEOzNU1RqxCT3Y5GM1VnUp3WH8IOAILo+5xA0TRpzwDJpYdMQLGSIeznsVbhsA=
Content-Language: en-us
X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a
Subject: RE: Proposed Statement on "HTTPS everywhere for the IETF"
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on
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:07:02 -0000

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 is clear that a solution has been chosen and language is being collected to justify that solution. Again, I am not opposed to the solution, just the unnecessary method being used to justify it. All you need to do is state the clearly justifiable requirement for data integrity. The fact that the chosen implementation goes beyond the requirement is a bonus for those who want the privacy. 

Put another way; if the IESG believes it has the excess time to make clearly political statements (rather than focus on the justifiable technical requirement), maybe we need to revisit the workload on the NomCom and reduce the number of ADs...


> (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]