Re: Stricter TLS Usage in HTTP/2

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.

Yoav

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