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

"Tony Hain" <alh-ietf@tndh.net> Thu, 04 June 2015 15:37 UTC

Return-Path: <alh-ietf@tndh.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 33ABF1A89AB for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2015 08:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Level:
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 QFy1nGrwzUZE for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2015 08:37:55 -0700 (PDT)
Received: from express.tndh.net (express.tndh.net [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 ietfa.amsl.com (Postfix) with ESMTPS id 9D0151A899F for <ietf@ietf.org>; Thu, 4 Jun 2015 08:37:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:To:From; bh=wZALm4QtfcJrhyljS+v0dXQ4BpDGmSR8autPB5YhyLY=; b=ALdIzNROfx7xzdNO8QCjSCVpPK407B3vJ4gsKwVcM9rdDgm0lbyVbosfj063qZBucnmOCjo4u3Qh2JL2XbOaYQXN7Vwpf4R0O5VutKVkWSuvjLvg/9qXIy/3SpGY2Lt7lCBm1t6i1BPBFNTmYs0ANSm8vwhMW0reB4mitMHRQxoLHD8W;
Received: from express.tndh.local ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <alh-ietf@tndh.net>) id 1Z0XD7-000LZD-Dl; Thu, 04 Jun 2015 08:37:49 -0700
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'Brian E Carpenter'" <brian.e.carpenter@gmail.com>, "'Stephen Farrell'" <stephen.farrell@cs.tcd.ie>, <ietf@ietf.org>
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>
In-Reply-To: <556FC594.1080900@gmail.com>
Date: Thu, 4 Jun 2015 08:37:39 -0700
Message-ID: <0b9001d09edc$63df32b0$2b9d9810$@tndh.net>
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+5xA0TRpzwDJpYdMQLGSIezAiNwF/8CAIbo/56lB1yg
Content-Language: en-us
X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a
X-SA-Exim-Mail-From: alh-ietf@tndh.net
Subject: RE: Proposed Statement on "HTTPS everywhere for the IETF"
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on express.tndh.net)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/nP8FaBZYEvuT4x6GmK9RGkvUNsE>
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 15:37:56 -0000

Brian E Carpenter wrote:
> 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*..."

So that text exposes the silliness of this effort. IF there are people that really need privacy of their access of IETF content, they had better be using more than HTTPS. If they are not using something like TOR they are toast, because it doesn't take much traffic analysis to figure out which documents are being read. Anyone can create a mirror, and with that data they will know which documents and requests create which byte stream lengths. 

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

It is dangerous to imply that simple https provides any privacy when the original content is public information. If true privacy is the requirement then the IETF needs to be serious about expanding TOR. This proposed text is unnecessary theater to make a political statement. If the I* wants to make a political statement, the ISOC or maybe IAB should make it. The IESG has no business making anything more than a technical statement, and the only thing they need to say is that data-integrity is important so we are making https the default. The clear refusal to drop the word privacy from the statement just underscores how much this is politically driven rather than a serious effort to ensure that the IETF content is delivered intact. 

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. 

Tony

> 
>     Brian