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

Eliot Lear <> Tue, 02 June 2015 04:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A03391ACE9F for <>; Mon, 1 Jun 2015 21:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 56penRmXCPu4 for <>; Mon, 1 Jun 2015 21:44:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1DEF1ACEA1 for <>; Mon, 1 Jun 2015 21:44:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3338; q=dns/txt; s=iport; t=1433220247; x=1434429847; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=R5gZuLn6ggFDoyQfoxtF4LysEJZkrJlvS9nuBvMNYTM=; b=CVrLFUNQtz53e/1yIB9tM610h3u5JeO7HxKBFFgcj7zLDZyYw8okz+mw UdD6igTVL2W3bAetfxMWuFZ/L/tITT9O6FUnLZyM5SF2MYDnXyJcq0ASS wuiGNjqyOIv4798WpKcusKpRGJgTOezZLmh3/lm29/9XyMBP6/kSJgu13 U=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,537,1427760000"; d="asc'?scan'208";a="507387488"
Received: from (HELO ([]) by with ESMTP; 02 Jun 2015 04:44:05 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id t524i5QN006139 for <>; Tue, 2 Jun 2015 04:44:05 GMT
Message-ID: <>
Date: Tue, 02 Jun 2015 06:44:05 +0200
From: Eliot Lear <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
References: <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sNskvFNu9D0oEB38wC5H64OCUI2lHb7B9"
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: Tue, 02 Jun 2015 04:44:09 -0000

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),
but because we need to be eating our own dog food so that we understand
the sorts of pitfalls others will face when we emplore them to encrypt. 
This way we can first face those issues and perhaps address them.

It would be helpful to understand what this statement will mean in
practical terms in the near future.  If what we are saying is that the
secretariat will pursue alternatives to the current rsync / ftp
approaches, that's fine.  It's what I was suggesting in the last round
of discussions.  Is git in our near future (not objecting, just wondering)?

With regard to plain text, it would be helpful if the secretariat could
report how much plaintext is actually accessed, and if at all possible,
by the number of different "users", so that we can determine when – if
ever – to turn off plain text.  It may also help us understand if there
are certain geographies that are not accessing encrypted information.

And yes, as always, I prefer decisions to be documented in RFCs but I
care far less in this case, since it is a policy that would direct the
secretariat and not participants.


On 6/1/15 6:43 PM, The IESG wrote:
> Hi All,
> The IESG are planning to agree an IESG statement on "HTTPS Everywhere
> for the IETF," please see [1] for the current text.
> We are seeking community feedback on this and welcome assistance
> from the community in identifying any cases where a change or
> additional guidance is needed to put this into effect.
> The IESG plans to finalise this statement just after IETF-93 in Prague.
> * Please send general feedback intended for discussion to
> * Comments about specific issues arising can be sent to
> or as appropriate (use if not sure)
> Regards,
> Terry & Stephen (for the IESG)
> [1]