Re: Stricter TLS Usage in HTTP/2

On 5 June 2014 11:32, Daniel Stenberg <daniel@haxx.se> wrote:
> 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.

Broadly agreed: I acknowledge that there are open-source TLS
implementations that support ALPN, and I'll be looking at them
closely. However, the notion that there's "nothing that prevents me"
from working with TLS libraries to get ALPN into a release version is
untrue. I am not paid to do open-source HTTP/2 development: I do it on
my own time. I get no commercial or financial support. I also have
other responsibilities, both open-source and personal. This means I
have an extremely limited pool of resource for moving things forward,
especially things that are not under my complete control (like TLS
libraries). Getting ALPN support ends up being a huge time-sink for
me, either as a rewrite of my own code (to use NSS and make installing
it something less than a total pain in the ass) or forcing through
support of ALPN on other platforms (read OpenSSL). Agreed that this is
not the same as "impossible", but it's certainly a long long way from
"easy".

> 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'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?

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.

Received on Thursday, 5 June 2014 10:57:15 UTC