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

[Cas Cremers <[e-mail]>]

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