Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)

Daniel Kahn Gillmor <> Wed, 11 December 2013 21:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8C2CA1AE148 for <>; Wed, 11 Dec 2013 13:50:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w2NWA41xQp7k for <>; Wed, 11 Dec 2013 13:50:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9E8DF1AE11B for <>; Wed, 11 Dec 2013 13:50:39 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 73697F984; Wed, 11 Dec 2013 16:50:32 -0500 (EST)
Message-ID: <>
Date: Wed, 11 Dec 2013 16:50:29 -0500
From: Daniel Kahn Gillmor <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: Yoav Nir <>, IETF TLS Working Group <>
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0T79H357P7C6LS2v0lgjIj23hmdM9mWd8"
Subject: Re: [TLS] A new consensus call on ALPN vs NPN (was ALPN concerns)
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: Wed, 11 Dec 2013 21:50:41 -0000

On 12/11/2013 10:16 AM, Yoav Nir wrote:
> I think it's possible to get all the extension hiding we want in TLS 1.3, even while keeping BC with TLS 1.0 servers:
> 1. Client sends ClientHello without the problem extensions (ALPN, SNI). The record version is 3.1 (TLS 1.0), while the supported version is 3.4 (TLS 1.3). 
> 2a. The server replies with TLS 1.3, and everything works as planned. The end.
> 2b. The server replies with TLS 1.0, and some certificate. The certificate may or may not fit the site. Makes no difference for now.
> 3b. The client completes the exchange, and immediately begins a renegotiation
> 4b. In this renegotiation, the versions offered are just TLS 1.0 to TLS 1.2, and all extensions are present (though encrypted).
> 5b. The renegotiation completes at TLS 1.0 with all extensions.

This approach should work to hide all extensions in current versions of
TLS as well, right?  But no one does it, as far as i know.

Do you know of any TLS client library which does this, or provides an
option to do it without a bunch of manual intervention in the workflow
of the TLS stack by the library user?  Do you think certain tools or
users should be doing this now?

Are there any extensions which require that their content must be
identical across session resumption or across a re-handshake?

If so, it doesn't seem like those extensions could be used in this
re-handshake approach.