Re: [TLS] Commentary on the client authentication presentation slides

Before people get too far down that road, here:

https://tools.ietf.org/html/draft-thomson-httpbis-cant-01
https://tools.ietf.org/html/draft-thomson-tls-care-00

Andrei has made it clear that these do not work for his use case (I'm
not yet convinced that they are inadequate, but I am convinced of the
fact that Andrei thinks that they are inadequate ;).

Also:

https://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.9

This is well-trodden ground.

On 10 August 2015 at 23:05, Dave Garrett <davemgarrett@gmail.com> wrote:
> On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote:
>> > What sort of usecase you have in mind for this?
>>
>> This is to support a fairly common website design where the landing page does not require client auth, but subsequent request to a protected resource triggers client authentication within an existing TLS connection.
>> In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no renegotiation, so we need an alternative solution if we want to support these existing sites over TLS1.3.
>
> This is just an idea, but what about just allowing a renegotiation-like mechanism via 0-RTT with PSK resumption to be triggered on a TLS alert or HTTP response code? The rough idea would be like this:
>
> 1) client connects to server and fetches public resources
> 2) client requests restricted resource; server sends auth required response (TLS alert or HTTP code)
> 3) client creates a replacement connection using PSK-based resumption and early data in the first flight for the request along with the client cert.
>
> There's a 1 roundtrip cost in there for a new TCP connection, which could possibly be optimized away by using TCP fast open.
>
> This general concept is relatively simple in comparison to doing something mid-connection. Instead of attempting to renegotiate on an existing connection, just make creation of resumed connections cheap enough to start over with client auth in the handshake from the start.
>
> It's a very rough idea, but I'm wondering if it sounds like something worth discussing.
>
>
> Dave
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls