Thanks everyone, we will try to wrap up the situation and remaining issues.
TL;DR: The problem that we identified applies to fewer situations in the real protocol than we thought, because of our previously coarse modelling of the AEAD. However, the main issue remains: the client never receives an in-band confirmation that the client authentication has succeeded. From a formal perspective this means there can be a mismatch between the view of the client and the server. We suggest this is made explicit in the security guarantees section. Furthermore, supposing the client has a way to determine whether authentication was successful, there still exists the possibility that the client receives messages whose context is ambiguous. In more detail: 1. Ordering of messages, which is enforced by the AEAD, means that property (A) we discussed is not an issue. The client knows that any message sent after the certificate will arrive (be processed) at the server after the certificate. 2. Property (B) is still an open issue for both the initial handshake and post-handshake. Application messages sent by the server can easily be delayed (by network or adversary) and the client cannot determine whether this message was sent before or after the authentication was received and therefore under the assumption that the client is an authenticated peer or not. 3. There is a small asymmetry between the initial handshake and post-handshake. If the client authenticates in the initial handshake, receiving post-handshake messages (such as a NewSessionTicket), must come after the client's certificate/finished is processed. This is enforced cryptographically since the RMS is computed using the Finished messages. In contrast, NST messages can arrive ambiguously before/after a post-handshake client authentication. The main takeaway is that the client never really receives any acknowledgement of whether the verification provided was successful or rejected through an in-band mechanism. The context of the keys does not include the client’s authentication status (nor the client’s certificate), and is the same in both cases. From a formal analysis point of view, this results in a mismatch where the client and server may not agree on the mutual authentication status, which is the main point we wanted to raise. Assuming now that the key context will not be changed, we suggest to explicitly mention in the security guarantees section that the client, after sending authentication messages, cannot be sure at any point that the server has received these messages and considers the connection to be mutually authenticated. If the client wishes to obtain such a guarantee, it has to be informed by the server’s application. Best, Cas Cremers, Marko Horvat, Jonathan Hoyland, Thyla van der Merwe, and Sam Scott
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
