Re: [TLS] Review of PR #209

[Martin Thomson <[e-mail]>]

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.)