Re: Stricter TLS Usage in HTTP/2

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: 
http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1716.html

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