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

Re: Stricter TLS Usage in HTTP/2

From: Yoav Nir <ynir.ietf@gmail.com>
Date: Thu, 5 Jun 2014 16:01:27 +0300
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DE62A9EF-CBF6-4D1A-8D6E-071A7BBE0089@gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>

On Jun 5, 2014, at 1:56 PM, Cory Benfield <cory@lukasa.co.uk> wrote:

>> 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.
> What it says is "screw those languages and environments, they should
> be more popular or get commercial support". The ability to quickly
> move to support new features is granted by developer time, and that is
> obtained either through popularity or financial support. My
> implementation has neither. If your advice is that I should abandon my
> implementation then fair enough, but otherwise I'm going to at least
> raise an objection to onerous burdens.

I donít think any of Java, OpenSSL or Python are lacking in popularity. That they are not updated with things that havenít made it yet to RFC is more a testament to their huge install base that makes them slower to react, but not actually slow. I would have liked it if OpenSSL to add ALPN if 1.0.0x and 1.0.1x, but thatís their choice, I guess. 

> I'd like to point out that ALPN and NPN are, as Yoav mentioned, not
> security features. I've not complained about using new versions of TLS
> or more secure TLS configuration, despite the fact that it has also
> caused me difficulty. This is because I am in agreement: more security
> is good, and I'm happy to expend my limited time on improving that.
> I'm less delighted about being boxed in on features that fundamentally
> have nothing to do with security and, as far as I can tell, everything
> to do with "this didn't come out of the IETF so it sucks". Why are we
> abandoning a protocol with a broad installed base?

We are abandoning NPN - an experimental extension used for nothing except negotiating SPDY, itself an experimental feature. Hopefully, but the time HTTP/2 is an RFC there will be a non-beta version of OpenSSL with ALPN. Regarding Java, I have no idea.

> I don't expect to prevail on this point: the ALPN decision was made
> long ago and it's clear that I'm in a very small minority of people
> who are affected. I can also appreciate why supporting both NPN and
> ALPN is a long-term undesirable state of affairs. I don't even think I
> really disagree with the specification, and I certainly don't think
> there's any malice here. I just want to alert the WG to the fact that
> this aspect of the spec is inconvenient. Basically I want the WG to
> come out and say "Yes, we know it's inconvenient, and no, we don't
> care". Then I'll get off my soapbox and shut up.

The spec is currently a draft. Although itís not likely at this stage, anything in it can change, so all implementations based on it are necessarily experimental, even if theyíre put in production.

Received on Thursday, 5 June 2014 13:02:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC