W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Stricter TLS Usage in HTTP/2

From: Daniel Stenberg <daniel@haxx.se>
Date: Thu, 5 Jun 2014 12:32:52 +0200 (CEST)
To: Cory Benfield <cory@lukasa.co.uk>
cc: Martin Thomson <martin.thomson@gmail.com>, ChanWilliam(Dz) <willchan@chromium.org>, "Richard Wheeldon, (rwheeldo)" <rwheeldo@cisco.com>, Yoav Nir <ynir.ietf@gmail.com>, Patrick McManus <mcmanus@ducksong.com>, Adam Langley <agl@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.DEB.2.00.1406051224050.28365@tvnag.unkk.fr>
On Thu, 5 Jun 2014, Cory Benfield wrote:

> On 4 June 2014 17:58, Martin Thomson <martin.thomson@gmail.com> wrote:
>> We have chosen the first option. The document didn't say MUST, but it is
>> still normative this regard.
> Ah, I didn't spot that in the document. Well that's exceptionally awkward 
> for me. And let's not beat around the bush, NPN is not just 'more 
> accessible', it's basically 'the only option'. Until OpenSSL 1.0.2 comes out 
> ALPN is unavailable to me (and to many other implementations).

This is not really true. curl supports client-side ALPN (and subsequent http2) 
right now using one of 4 different TLS libraries. Sure, if you want the 
bleeding edge functions to may use a bleeding edge/non-released version during 
development. But there's nothing that prevents you from doing so or from 
working with those TLS libraries to get ALPN into a release version you can 
use. I believe PolarSSL, GnuTLS and NSS already do.

This ("we can't use new TLS features") is the same argument already iterated 
numerous times usually from Java people and I've argued against it before: 

I would reverse the argument and say that if your languauge/environment cannot 
keep up with protocol development then perhaps that says something.

Right now, it is also dead-simple at least for clients to simply use both NPN 
and ALPN (and pretending they're only one method) for the libs that can do it 
and over time when ALPN really takes off drop the NPN parts.


  / daniel.haxx.se
Received on Thursday, 5 June 2014 10:33:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:26 UTC