Re: [TLS] Review of PR #209

[Andrei Popov <[e-mail]>]

> The client is now uncertain about whether the server has remembered their certificate.  That's bad if there are actions that might be denied to the client in the absence of the certificate.

But the server will send a CertificateRequest in this case and the client will have a chance to authenticate. 

> You could say that the easiest remedy is to offer the certificate again, because that removes the uncertainty.  But a major reason for having resumption is to avoid the public key operations on both peers, so that's not a great solution.

That's why instead I say the client should send the ticket and if it turns out insufficient, the client will get a CertificateRequest :).

> ... but that doesn't mean that someone couldn't build a system that offers different content in response to client authentication AND that system could have TLS 1.3 clients authenticate without prompting in order to get that different content.

This is a new use case; with PR #209 I'm mostly trying to support existing use-cases. But if you want to enable this new scenario, we can consider something like this:
- CertificateRequest can include a random ID;
- Client Certificate and CertificateVerify would either echo the ID from a CertificateRequest, or use a new random ID if it's unsolicited;
- NewSessionTicket would use an ID matching the client Certificate/CertificateVerify.

This also solves the unsolicited vs. requested client Certificate issue we talked about earlier. This of course introduces a bit of extra complexity.

> After all, asking has consequences that you might want to avoid, like the "pick a certificate" dialog in browsers.  (Maybe you only need this behavior for bespoke clients.)

I'm not sure about this.

"Pick a certificate" dialog means that the client:
a) Does not know whether the user wants to send a credential to a server;
b) Does not know which of the multiple available credentials to send to the server.

If you have a system where the client app knows that a certificate is required, and knows the specific certificate to send, there is no need for the dialog. Such a system is ready to respond to a CertificateRequest (without showing the dialog), or it could send the certificate unsolicited. I think that uncertainty, not CertificateRequest, is the reason for the dialog.

-----Original Message-----
From: Martin Thomson [mailto:[e-mail]] 
Sent: Tuesday, September 15, 2015 4:53 PM
To: Andrei Popov <[e-mail]>
Cc: [e-mail]
Subject: Re: [TLS] Review of PR #209

On 15 September 2015 at 16:19, Andrei Popov <[e-mail]> wrote:
>> I'm concerned that this produces an indeterminate state on the server.
>> What if that Certificate doesn't conform to the request in some way: was the Certificate just a unilateral offer that was sent before the client received the CertificateRequest, is the client unable to understand the CertificateRequest, or is the client in error?
>
> Traditionally, it was not an error for the client to send an empty Certificate message, or to offer a credential that does not match the parameters in the CertificateRequest. From the server's perspective, it doesn't matter what went wrong: the server treats the client as unauthenticated in this case (and possibly alerts/disconnects).

Right, but not all applications work on that model.  Some make the request and block on a response.

> Because we want to allow the client to volunteer a certificate, there can be a situation where the server sends a CertificateRequest and receives an unsolicited client cert before the client can respond to CertificateRequest. We can add a flag to the client Certificate message to distinguish unsolicited creds from requested ones. Would this address the concern?

That would work.

>> That doesn't work for clients that send credentials without prompting.
>
> Not sure what you mean, can you elaborate on the scenario?

Client connects to server and completes the handshake.
Client sends certificate immediately after Finished.
Server sends NewSessionTicket after seeing Finished or CertificateVerify; client is unable to tell which.
Later, Client resumes using the ticket.

The client is now uncertain about whether the server has remembered their certificate.  That's bad if there are actions that might be denied to the client in the absence of the certificate.

You could say that the easiest remedy is to offer the certificate again, because that removes the uncertainty.  But a major reason for having resumption is to avoid the public key operations on both peers, so that's not a great solution.

This isn't a problem with TLS <=1.2, because there is no client authentication without prompting, but that doesn't mean that someone couldn't build a system that offers different content in response to client authentication AND that system could have TLS 1.3 clients authenticate without prompting in order to get that different content.
After all, asking has consequences that you might want to avoid, like the "pick a certificate" dialog in browsers.  (Maybe you only need this behavior for bespoke clients.)