Re: [TLS] Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard

Alyssa Rowan <> Fri, 13 December 2013 19:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 445D81AE3D9; Fri, 13 Dec 2013 11:42:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 876U4vE7Wit8; Fri, 13 Dec 2013 11:42:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 291FA1ADF6B; Fri, 13 Dec 2013 11:42:42 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 0D21F60A2D; Fri, 13 Dec 2013 19:42:35 +0000 (GMT)
Message-ID: <>
Date: Fri, 13 Dec 2013 19:42:27 +0000
From: Alyssa Rowan <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Dec 2013 19:42:47 -0000

Hash: SHA512

On 13/12/2013 17:27, Paul Hoffman wrote:

> A hum was taken at IETF 87 for the WG to pick between this
> proposal and another; there were many hums in the room for each,
> with more for this proposal. That hum was not taken to the WG
> mailing list. Since then, many people have given strong reasons to
> prefer the other proposal for technical reasons.

Strongly seconded. This cryptographic protocol is not ready yet, and
requires careful reconsideration on-list, and at the very least a
public on-list call for consensus - which it does not seem to have
received - before deciding whether it is appropriate to proceed.

• At IETF 88's Technical Plenary, serious concerns were raised about
  mass surveillance of data and metadata by Nation State Adversaries.

• Decisions were made at IETF 88, with overwhelming consensus, that
  new protocols MUST consider the impact they have on mass surveillance.

• ALPN has no such consideration. It leaks plaintext metadata which its
  competitor, NPN, encrypts. This makes ALPN quantitatively more
  vulnerable to passive attackers, including Nation State Adversaries.
  [It may be that a future TLS 1.3 can encrypt the whole ClientHello;
  but that is not the current state-of-play. As it stands, it would be

• Profound concerns have been raised about the protocol and the voting
  process. A call has been made for at the very least the opportunity
  to stop, rewind, and rethink whether ALPN is appropriate, and for a
  new consensus call.

• The chairs and AD have refused, and simply ignored the concerns.

• It is publicly known that Nation State Adversaries have attempted to,
  and in some cases succeeded in, weakening or backdooring
  cryptographic standards. TLS has very likely been a main target of
  this, as the most-used cryptographic standard on the internet.


• Concerns have been raised that one or more of the chairs or AD may
  have a conflict of interest and appear to be railroading the process.

• As discussed at the IETF 88 Plenary, especially in light of the
  Snowden BULLRUN disclosures, it is absolutely vital that
  cryptographic standards such as TLS are devised openly,
  transparently, and with clear, public consensus as being the best
  available solution.

• That has not happened with the ALPN extension to date.

Therefore, I second Brian's proposal for a new consensus call and
discussion on ALPN, and Paul's appeal to the IETF LC: in my opinion,
it is wholly premature to advance ALPN to Proposed Standard at this time.

- --