Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

[Sam Scott <[e-mail]>]

Hi Ilari,

Thanks for the comments.

Assuming the client sends a valid certificate that the server accepts, 
then the server cannot finish the handshake or begin processing incoming 
application data until authenticating the client. This *almost* gives us 
property (A). In practice, the client is aware that the server has 
successfully authenticated since the protocol continues.

In the case that the server has implemented the reject option (rejecting 
a certificate but still continuing), and indeed rejects the certificate, 
then the server should send an alert message (or NAK of some form) for 
the property to hold in the initial handshake.

However, even if we take the certificate reject + continue scenario into 
account for the initial handshake, then it is clear that this decision 
can only be made by the server in the initial handshake, while in the 
post-handshake client auth, an attacker can decide this (by dropping the 
message).

The reason we don't believe an explicit ACK is needed is because 
upgrading to a new pair of keys explicitly provides this. Specifically, 
the client will send all subsequent data to the server under a new key. 
The server will not be able to decrypt this data until they receive the 
client authentication messages and upgrade the keys.

This can be strengthened if the client's updated write key is computed 
using the authentication messages.

We agree that TLS enforcing ordering of messages provides similar 
guarantees. However, we are analysing the specification as it is 
presented, which does not guarantee this.

Thanks,

Sam