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 <davemgarr...@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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
