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 20:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C11CC1A1F78; Sat, 14 Dec 2013 12:35:49 -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 Y5zHjgQ3okum; Sat, 14 Dec 2013 12:35:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B2A251A1F66; Sat, 14 Dec 2013 12:35:29 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 8AFA760A73; Sat, 14 Dec 2013 20:35:21 +0000 (GMT)
Message-ID: <>
Date: Sat, 14 Dec 2013 20:35:23 +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: <> <> <> <> <> <1387025259.17660.17.camel@aspire.lan>
In-Reply-To: <1387025259.17660.17.camel@aspire.lan>
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: Sat, 14 Dec 2013 20:35:50 -0000

Hash: SHA512

On 14/12/2013 12:47, Nikos Mavrogiannopoulos wrote:

>> [Limiting ALPN to HTTP/(1|2)]

To clarify, I specifically propose (Security Considerations?):

  It is NOT RECOMMENDED for a client using ALPN in TLS 1.2 to identify
  supported protocols other than HTTP/1 or HTTP/2: signalling that
  other protocols are supported could reveal more fingerprinting,
  targeting or application metadata in plaintext than is desirable or

  This caveat does not apply if the ClientHello is protected from
  passive eavesdropping [as in a future version of TLS].

(Subject to argument, of course.)

> I don't see any advantage in your proposal. Why restrict ALPN from
>  negotiating anything else than HTTP?

• It minimises plaintext fingerprinting.
  - Eve trivially knows every protocol Alice advertises support for.
  - Ideal if Eve wants to become Mallory and has a tailored exploit
    for one of them.
    · Real scenario: QUANTUM, EGOTISTICAL GIRAFFE, etc
  - Please let's keep that to a minimum, while it's still plaintext.
• Why use ALPN (or NPN!) for anything?
  - Why _indeed_ not use a port number? POP3 got one. Why not HTTP2?
  - Because of port-blocking firewalls disallowing all but port 80/443.
  - Many non-IETF protocol deployments bitten by this chose to use 443.
    · Tor
    · Several VPNs, including SSTP, and commonly OpenVPN in the wild
    · Skype [not that that's a _good_ protocol, just a common one!]
  - So multiplexing on 443 is considered fairly commonplace/desirable.
  - But DPI firewalls, even simple ones, can read ALPN if plaintext.
    · So they'd block those, too. Then what? Stop using ALPN? Lie in it?
• Most of all, because: it's HTTP/2 that needs it _right now_.
  - Other things can have it later, in TLS 1.3, when it's much safer.

At this point (post-IETF 88) if we were redesigning UDP or TCP, we'd
certainly consider encrypting the port numbers, if it were practical,
wouldn't we?

As far as your point that NPN is a bit of a hack, I agree.

It may be better to have ALPN in a limited fashion now, so that Martin
and the httpbis WG can proceed - I do not really want to delay their
fine work - and encrypt the whole ClientHello later in TLS 1.3.

Therefore, upon reconsideration, I withdraw my objection to ALPN
progressing to Proposed Standard.

I do wish for my caveat above to be noted under Security
Considerations, although this is of course subject to argument,
as others may not agree.

I apologise for any inconvenience caused.

- --