Re: Stricter TLS Usage in HTTP/2

Hi Cory.

ALPN has no security advantage over NPN. The reverse can be argued. It is, however simpler and more in line with “the way we do things in TLS”, so the TLS working group selected ALPN over NPN. ALPN will soon be an RFC, whereas NPN won’t.

OpenSSL was very quick to implement NPN, so it’s strange that they are very slow to implement ALPN. I wish I had a better answer than “take it up with them” or “that’s life”. Unfortunately, I don’t.

Yoav


On Jun 5, 2014, at 10:43 AM, Cory Benfield <cory@lukasa.co.uk> 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). For organisations large enough to be using their own
> crypto libraries Even when it does come out it'll be functionally
> unavailable to me for several more months, given that I'll have to
> plumb support for it through three separate OSS packages all of which
> run on their own schedules. (I speak from experience here, having
> started adding NPN support to PyOpenSSL in March and still not having
> the pull request merged.)
> 
> What's the rationale for (effectively) putting the normative MUST on
> the technology that is harder to get hold of? Is there a meaningful
> security advantage of ALPN over NPN?

Received on Thursday, 5 June 2014 08:45:55 UTC