W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

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

From: Yoav Nir <ynir.ietf@gmail.com>
Date: Thu, 3 Apr 2014 11:59:29 +0300
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <CC74D529-2110-4E8F-9F26-6B976ABB5354@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC