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

On Apr 1, 2014, at 8:56 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 1 April 2014 04:02, Yoav Nir <ynir.ietf@gmail.com> wrote:
>> #1 is not a bad option. It’s not pretty, but just the fact that it’s written
>> down puts it ahead (process-wise) of the others.
>> 
>> The TLS working group is considering getting rid of renegotiation for TLS
>> 1.3, because few use it except for client authentication in HTTPS. Going
>> with option #2 leaves us with all of the complexity. I’d rather we didn’t go
>> there.
> 
> This is why #1 perhaps has the edge on #2.  If we consider the
> possibility that renegotiation could be impossible in TLS 1.3, then a
> new connection is the only real option.  Either that or something RFC
> 5705-based, like #4.
> 
> As Patrick infers, I'm not that keen on #1.  But I do want a solution.

I agree that #1 is the best way forward, because:
 - It can easily work with HTTP/1 which is not dead yet
 - It reduces complexity, especially eliminating the transition from non-authenticated to authenticated state mid-connection.

I’m not too worried about the latency. For browsers, choosing a certificate as part of the log-in process is one of those things that users expect to take noticeable time, especially if it requires user interaction with a certificate picker. So starting a new TCP connection? Not that bad.

I’m wondering if it’s possible to write some sensible text on what to do with the two connections. Suppose a resource is fetched from a server, and the server sends the 401 response. The client opens a new connection, this time with client authentication. So now there are two connections, one authenticated, while the other is not. The triggering resource obviously has to be fetched in the authenticated connection. I suppose we let all in-transit streams conclude normally, but what does the client do with any other resources that it needs. Do they go in the old or new connections? What about pushed resources from the server?  Does the server even know that the two connections are associated?  Probably not (unless there’s some outside mechanism at work such as cookies). Does the client close the original (non-authenticated) connection once the streams are closed?

I guess we’ll have to answer all of those if we choose #1  (not that the questions for the other solutions would be any less difficult)

Yoav

Received on Thursday, 3 April 2014 09:00:03 UTC