Subject: TLS Renegotiation and HTTP/2 (#363)

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Mar 2014 17:11:59 -0700

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

---

From: Patrick McManus <[email-masked]>
Date: Mon, 31 Mar 2014 23:52:58 -0400

Martin - when you put it like that.. yeach!

I'm glad to hear you're not terribly enamored with option #1 - it seems
like there are process dragons there and since it requires a new connection
and handshake it isn't exactly winning any performance merit badges either.
I was a little nervous about that road.

At least given this presentation, #2 does take on a certain shine it hasn't
really had in the past :). The quiescent issues can always be bounded with
RST_STREAM if that's a priority for the application. It actually doesn't
strike me as terribly complex to describe or implement. Operationally I
think some degree of awkwardness is going to be connected to any of these.

3 and 4 seem considerably less desirable to me. 5 is ideal but
insufficiently described for standardization :)

-P