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
