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

Watson Ladd <> Sat, 14 December 2013 00:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 85D7D1AE00D; Fri, 13 Dec 2013 16:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_71=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N4GBsDwcOD2g; Fri, 13 Dec 2013 16:47:31 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c03::22c]) by (Postfix) with ESMTP id 594721ADBCD; Fri, 13 Dec 2013 16:47:30 -0800 (PST)
Received: by with SMTP id w62so2596281wes.3 for <multiple recipients>; Fri, 13 Dec 2013 16:47:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=i6HzZsGH0K4dbirMkzBP9dyMupnlFKYsrQ8bJ2oZ9RM=; b=UMkiMPGXLhUB2iG9T2uQakQlKNnyhT9P8BSV4GVDL/o21AqMxMncCCdkH2QRImIjkz 1ebMZxwWQQJGEx9TsCTt+iNSbYWAUz+1vHJC4gwzcLsrA84DFkDaEUSJ9NY/h1waHvV8 47rSWDJ/x6I2FG6oTZAgOR3qe8Rzsb/C9s2x/ZkSj44smtnnRE0B5ZQvpdPNV/7BY2vl /smCDTvODJwDgAE6NOpfHZG9ZYPuifUA/7wr8OP1+A8ipIzNvx8untr+I1CwM3xA/I7R o9mS1kTZBQbz/YK4KiydNmHctgMUyRLkHYmMHu++S3adfiuwlU43onobZudhf3k1cUV6 GgUw==
MIME-Version: 1.0
X-Received: by with SMTP id fb10mr4472197wjd.50.1386982043445; Fri, 13 Dec 2013 16:47:23 -0800 (PST)
Received: by with HTTP; Fri, 13 Dec 2013 16:47:23 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Fri, 13 Dec 2013 16:47:23 -0800
Message-ID: <>
From: Watson Ladd <>
To: "Stephan Friedl (sfriedl)" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "<>" <>, "<>" <>, "<>" <>
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:47:33 -0000

On Fri, Dec 13, 2013 at 4:28 PM, Stephan Friedl (sfriedl)
<> wrote:
> I fear that there is a perception that ALPN leaks information like a sieve and NPN doesn't leak at all.  Both extensions leak information in plain text - they just leak different information.
> NPN leaks the entire list of protocols available on a host/port combination and encrypts the single protocol selected by the client.  When watching a single TLS negotiation using NPN, a passive attacker knows all the protocols exposed by a server and therefore has a big head start on identifying the single protocol chosen by the client as well as assessing a server for potential vulnerabilities to exploit - effectively an instant port scan.  In contrast ALPN has the client advertising the protocols it supports in plaintext and has the server's selection of a protocol returned in plaintext.  In ALPN the entire list of protocols supported by a given host on a given port is never revealed during a single TLS negotiation.

Clients are much more interesting to watch than servers. So long as
ALPN and NPN are negotiating among a small number of protocol versions
this doesn't matter. But if we include various options in HTTP this
makes fingerprinting easier if they are exposed in ALPN. Scanning for
what a server supports looks like a bunch of diverse clients
connecting: it isn't going to get noticed anyway. But knowing that a
client supports the latest Firefox+a particular extension because it
has support for a protocol over 443 is very useful. I don't think the
extra few bits matter, but we should remind everyone that they should
be very few bits. (In particular the inevitable hack advertising IRC
support via ALPN is a terrible idea).

> Also, I agree with Yoav's take on ALPN as simple networking and not a 'cryptographic protocol'.  All ALPN does is provides the protocol to be used for a connection when the port number is no longer definitive.  ALPN is a plain, vanilla extension - whereas NPN does introduce some non-standard twists to TLS extension practice in that the negotiation is not encapsulated in the hello messages and that it introduces a padded handshake message between the ChangeCipherSpec and Finished messages.

ALPN needs to be negotiated and tied into the session. Otherwise you
can have fun playing wrong protocol with right authority games.

Watson Ladd