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

Alyssa Rowan <> Sat, 14 December 2013 00:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3F3B41AE173; Fri, 13 Dec 2013 16:50:51 -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 H33ls9MJYF_f; Fri, 13 Dec 2013 16:50:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 63EF21AE14B; Fri, 13 Dec 2013 16:50:47 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 56C85602C5; Sat, 14 Dec 2013 00:50:39 +0000 (GMT)
Message-ID: <>
Date: Sat, 14 Dec 2013 00:50:38 +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: 7bit
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: Sat, 14 Dec 2013 00:50:51 -0000

Hash: SHA512

On 13/12/2013 21:43, Yoav Nir wrote:

> I mostly agree with the facts presented below. However: - I object
>  to characterizing this as a "cryptographic protocol".

Fair enough. Poor choice of words on my part. ALPN is a metadata
extension to the cryptographic protocol, TLS.

> [...]we now have TLS tell us whether there's HTTP/1 or HTTP/2 
> inside.

The I-D doesn't seem to limit this to HTTP/1 or HTTP/2: it's a general
extension, which suggests a general use case.

If HTTP/(1|2) is all it's really intended to be used for at this time,
(your and Martin's response makes me think maybe it is), then perhaps
we SHOULD only use it for that at this time.

I think that would substantially weaken my objection. How would others
feel about that?

And then later (TLS 1.3?), if we can encrypt the ClientHello [How?
Ed25519+Elligator2 key from DNSSEC, or something? Hm... not sure.],
then ALPN is fine. That might be a way forward, perhaps.

> - Mass surveillance is a concern. It is not the only concern.

I agree (though it is of growing importance). Little metadata leaks
can still be important where they intersect.

> We haven't heard anyone explain what good knowing the version of 
> HTTP does to a nation state adversary.

Hypothetical case study:

If NSA had, for example, a practical attack on the RSA-RC4-(SHA|MD5)
ciphersuites that used likely known-plaintext prefixes ("GET /"...?)
along with biases in the keystream to, as they would say, "enable"
partial key recovery, ALPN would mean they don't even have to guess
which prefix to try, and might be able to make it easier for non-HTTP
use of TLS.

Of course, that's just my own guess, and the BIG vuln there is RC4
(which can be (I hope) dealt with by Adam's draft).

ALPN would, I appreciate, be a help in packet classification/shallow
analysis, mostly if more widely deployed among other protocols.

I note Stephan's comments about NPN's own leaks, and so NPN could be
more useful to them in "CNE" (hacking), when the gloves come off.
There are benefits and drawbacks to both - I accept that.

> - The chairs did not ignore the requests. They rejected them.

They said that no substantive new information had been presented since
the initial consensus call and therefore the consensus should stand.
(They did state that objections could be raised during IETF LC: that's
what's happening now.)

The disclosures re: BULLRUN and the IETF 88 TP seemed simply
unaddressed. I find that baffling. It is, as you say, rushed. It looks
like railroading, and I'm sure all want to avoid that appearance.

If the WG indeed knew then what we know now, then if we took a quick
consensus on-list, it'd have a similar result, and all would see that
it has been reached openly and transparently, which would address the
concerns that have been raised?

> While I prefer ALPN, I wouldn't consider it tragic to have had 
> NPN.

Similarly, I prefer NPN, but I'm not vehemently against ALPN,
particularly if limited in scope to HTTP/1 or /2 until ClientHello can
be encrypted in TLS 1.3.

On 13/12/2013 22:46, Martin Thomson wrote:

> As the editor of the spec that stands most to be affected by 
> faffing around here, I'd be strongly opposed to further delays.

Sorry! I do thank you for baking TLS in - I feel that's important -
and I really do apologise for the 'faff'. (This is not really how I
wanted to introduce myself, believe me!)

I feel that, as an extension to a protocol with a billion-dollar
target painted on it, it needs to be thought through, not rushed through.

I want to make sure legitimate concerns raised on-list are addressed,
not shortcutted, and that a transparent consensus, with current
information, not stale, can be reached.

A week or so, maybe?

- --