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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 02 June 2015 11:55 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 2DCD41B2D71 for <ietf@ietfa.amsl.com>; Tue, 2 Jun 2015 04:55:38 -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 Ze20blyGYzZa for <ietf@ietfa.amsl.com>; Tue, 2 Jun 2015 04:55:37 -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 EE44B1B2D64 for <ietf@ietf.org>; Tue, 2 Jun 2015 04:55:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C105ABEE3; Tue, 2 Jun 2015 12:55:35 +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 pYWHkcOopsHV; Tue, 2 Jun 2015 12:55:34 +0100 (IST)
Received: from [10.0.65.147] (unknown [31.216.236.202]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 86E63BEDF; Tue, 2 Jun 2015 12:55:34 +0100 (IST)
Message-ID: <556D99B5.5030205@cs.tcd.ie>
Date: Tue, 02 Jun 2015 12:55:33 +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: Eliot Lear <lear@cisco.com>, ietf@ietf.org
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com> <556D3495.7090205@cisco.com> <556D41BC.8000307@cisco.com>
In-Reply-To: <556D41BC.8000307@cisco.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EIlkgsG7vTIGevpNA1O25uUWmc9uwftdO"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/T8gGLXL4GDziR65rXLXS-TcHAu8>
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: Tue, 02 Jun 2015 11:55:38 -0000

Hi Eliot,

I think the work to be done is fairly obvious for most things,
for example replacing http URIs with https URIs in new I-Ds,
though HSTS over all our domains has a bit of trickiness. We'll
also probably want to talk with the meetecho folks to see what
can be done there, that makes sense to do. More generally, I'd
expect this'll basically turn into a standing requirement (like
IPv6) that the secretariat will build into consideration of
ongoing or new work and it'll just be handled as we go.

One thing we'll all want (I hope:-) to do is to go edit our
bookmarks - I used have a load of those with http URIs and it's
really easy to forget to update those.

Cheers,
S.


On 02/06/15 06:40, Eliot Lear wrote:
> This is what I get for sending BEFORE coffee:
> 
> On 6/2/15 6:44 AM, Eliot Lear wrote:
>> If I understand the intent of this statement, that this is for IETF
>> services to be encrypted via TLS at this point in time, and that clear
>> text will continue to be supported, then I strongly support that tooling
>> approach, statement or no statement, being pursued by the secretariat. 
>> I support this approach not because the IETF communications contain
>> massive amounts of private data (I wouldn't imagine this is not true)
> Make that "I would imagine this is not true."
> 
> Eliot
> 
>