Re: [TLS] Review of PR #209

[Andrei Popov <[e-mail]>]

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

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 doesn't work for clients that send credentials without prompting.

Not sure what you mean, can you elaborate on the scenario?

> Would you be OK with saying that NewSessionTicket can only be sent in response to CertificateVerify or Finished?

Absolutely.

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

On 15 September 2015 at 15:03, Andrei Popov <[e-mail]> wrote:
>> That is, how does the server identify whether this is unilateral or in response to its own request?
>
> The model I'm thinking of is where the server receives a request from the client, determines that the request requires authentication, then queries session state to see whether a suitable client credential is available.
> If such client credential is not available, the server sends CertificateRequest. In this model, it does not matter whether the client volunteered a credential or responded to the server's request.

I'm concerned that this produces an indeterminate state on the server.
Say that the server receives a Certificate after it sends CertificateRequest.  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?  Depending on which of these is really the case, the server is unable to decide whether it should continue awaiting a Certificate or not.

It's not a huge issue, but I'd be happier if we nailed this sort of thing down.

>> How does a client determine if the NewSessionTicket that it receives 
>> includes its authentication? That is, how can a client know whether a 
>> resumed session will need a certificate or not?  (I'm not sure about 
>> this one, but the first thought that occurs is that the server could 
>> include an indicator in the NewSessionTicket message.)
>
> I'd say the client should send the latest ticket it has, assume that it has all session context including client identity, and the server will request creds if this is not the case.

That doesn't work for clients that send credentials without prompting.

>> What value do you see in having a spontaneous NewSessionTicket messages?  Is this just a case of not wanting to bind it more formally to something that the client sends?
>
> The reason I want to allow NewSessionTicket messages in mid-stream is to allow the server to include newly obtained client creds in the session state. If the server wants to do this, it can send NewSessionTicket after processing the client's CertificateVerify.

Would you be OK with saying that NewSessionTicket can only be sent in response to CertificateVerify or Finished?