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

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-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Tuesday, August 11, 2015 9:39 AM
To: Dave Garrett <davemgarrett@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 <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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls