- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Thu, 5 Jun 2014 08:43:49 +0100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: ChanWilliam(ιζΊζ) <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>
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 07:44:16 UTC