TLS Renegotiation and HTTP/2 (#363)

In my other email today, I've listed the items that are outstanding,
of which I identify 6 issues that could result in disruptive changes
to the protocol if we decide to act on them [1].

Of those, I think that TLS renegotiation is only the issue that fixes
something we've actually broken.  Broken, the sense that if we don't
do something about this issue, we've broken a feature that some people
rely on.  Importantly, this is broken in a way for which the only real
recourse is to revert to HTTP/1.1.

(Transfer-Encoding #445 arguably introduces a feature regression too.
But it's a regression that can be handled trivially by spending bytes.
 It might be reasonable to say that given the degree to which
Transfer-Encoding is used today, the odds that we are creating
incentive to stay on HTTP/1.1 is lower.)

Relying on renegotiation for re-keying (to avoid key exhaustion) seems
like a non-problem.  We already require the creation of new
connections when stream IDs run out.  It does mean that extremely
large requests or responses (broadly, anything longer than 2^64-1 TLS
records, though probably less if the cipher suite requires re-keying
earlier) cannot be carried at all.

The main issue here is client authentication.  I see several ways out:

1. Pursue http://tools.ietf.org/html/draft-thomson-httpbis-catch-00 or
something like it to the bitter end.  I don't see a way that we can do
this without creating a new normative reference, unfortunately, and
that work is clearly half-baked.

2. Allow for some very limited form of renegotiation for the client
authentication use case.  This might mean requiring that
MAX_CONCURRENT_STREAMS be wound back to 1 at the server before
renegotiation is triggered.  This avoids the dependency issue, and
might work for the use cases in question, but the cost in complexity
and loss of concurrency is extreme to the point that option 3 starts
looking good.

3. Force those using client authentication to stay on HTTP/1.1.  We
basically get this for free if we intend to pretend that this issue
doesn't exist.  I tend to think that this would be a bad outcome
though.

4. Resurrect the CREDENTIAL frame from SPDY.  My understanding of this
mechanism is that it would be non-trivial to add this to the protocol.
 It is quite a flexible mechanism, but one with significant costs.
This relies on RFC 5705 (TLS extractor) support, which is not
universally supported in the various TLS stacks that are commonly
used.  It also requires a new setting and modifications to the HEADERS
frame.

5. Something else that I haven't thought of yet.

Does anyone have a way forward to recommend?  My primary motivation
here is getting HTTP/2 done.


[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1292.html

Received on Tuesday, 1 April 2014 00:12:29 UTC