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

Alyssa Rowan <akr@akr.io> Fri, 13 December 2013 19:42 UTC

Return-Path: <akr@akr.io>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445D81AE3D9; Fri, 13 Dec 2013 11:42:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 876U4vE7Wit8; Fri, 13 Dec 2013 11:42:43 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 291FA1ADF6B; Fri, 13 Dec 2013 11:42:42 -0800 (PST)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) by entima.net (Postfix) with ESMTPSA id 0D21F60A2D; Fri, 13 Dec 2013 19:42:35 +0000 (GMT)
Message-ID: <52AB6323.2050107@akr.io>
Date: Fri, 13 Dec 2013 19:42:27 +0000
From: Alyssa Rowan <akr@akr.io>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20131213171608.10285.15352.idtracker@ietfa.amsl.com> <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org>
In-Reply-To: <9D6C4F2B-25ED-4A2A-AE89-03122D7213B8@vpnc.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: [TLS] Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2013 19:42:47 -0000

-----BEGIN PGP SIGNED MESSAGE-----
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
  plaintext.]

• 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.
  <https://www.ietf.org/mail-archive/web/tls/current/msg10892.html>

• The chairs and AD have refused, and simply ignored the concerns.
  <https://www.ietf.org/mail-archive/web/tls/current/msg10947.html>
  <https://www.ietf.org/mail-archive/web/tls/current/msg10948.html>

• 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.

<http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html>

• 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.
  <https://www.ietf.org/mail-archive/web/tls/current/msg10943.html>

• 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.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJSq2MjAAoJEOyEjtkWi2t6L0MQAIxsdB4aAZvw6XdiIttRzaHR
bmvvGCScckyUfSFS6t2V36oxp9FNmkEzaXUTpUcRMrJsRlsXgjExlIsYKYqvtPzi
x8zPRyc2Yp61zTj2tZI0tlYDwQ3M53Pfy1br+0eLfqqy+dRaPsRyQWHi9FlMLU5u
eGaA1KMgUOAZSxNB9oliJOXmSj+DcQpcWpp+D3piYBSINUYrY3xtO31khhG0f8xX
EOLH7pMwVkyEhQOG83qA801Yt45j0cr6X7Wg34jFhCfCR1xQDbkMLabAXHYTWmdo
C4cmJQVTHgnYXiIPdwXR87iPpAevBNpoxNQzps1LoHYEM6xpqDwln9aExyaPAiT6
4fV+Wr5C22H/Xh+wbkVFPRQEvZbbjDJKGSWyB0i6YKgmUxrF+VQHlJKFrS2TwEni
nmIIcFFN/bo2f8bwbtLf2bEQRAzz8R2N5gVeLQJcoWEz4lcl/1F2E82tZnd9ArLU
XGH5gawLh3bqLZRFUU0VfCYfQSrGy2PtIViyKSLKLCOlI7onL9CGB3jtSuqQDHep
8h3yeSk68d0gVVLmRUmx9aZMbOivZOP54t+Q8wwtluuHnGKdN2NU3oAFSfmDKcRG
cEWsddc44tF1eANVWXxJsHe8LvxUA6UCvI19kLxuNcV4RL8lCzWr38YaUVRpqXby
cYdzEMv6nqKpAynigGgh
=u0As
-----END PGP SIGNATURE-----