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

[Dave Garrett <[e-mail]>]

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