Indeed, I think cant-care has a number of disadvantages: 1. Introduces round-trips to establish a new TCP connection; 2. Requires a new TLS handshake, with associated costs. 3. Uses two CertificateRequests: one at the HTTP layer, and another at the TLS layer. Somehow we would need to figure out how to make them match, or have the client ignore TLS-level cert filtering parameters? 4. Pushes the problem to the application layer: any application protocol that uses mid-stream client auth will require an update. (I know, some will say we are only aware of HTTPS scenarios right now.)
At the cost of all of the above, cant-care allows the client to determine exactly which HTTP request has resulted in the client auth request. I think there may be a compromise where we can identify this HTTP request without requiring a reconnect. E.g. what about CertificateRequest at the HTTP layer + TLS client sending Certificate/CertificateVerify after the handshake in the middle of the existing TLS connection? Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson Sent: Tuesday, August 11, 2015 9:39 AM To: Dave Garrett <davemgarr...@gmail.com> Cc: tls@ietf.org Subject: 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 <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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
