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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
