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

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



On Mon, Mar 31, 2014 at 8:11 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

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