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

[Ilari Liusvaara <[e-mail]>]

On Fri, Feb 10, 2017 at 12:43:56PM +0000, Cas Cremers wrote:
> Dear all,
> 
> In the process of completing our Tamarin analysis of TLS 1.3 revision 18,
> we hit upon some behaviour that may lead to applications making incorrect
> assumptions. It is not an immediate attack, but we can imagine scenarios
> where it can cause problems. We describe it below, and show that it is
> possible to adapt the protocol (leveraging existing mechanisms) to avoid a
> mismatch.

Ah, Post-HS auth, one of the two things in TLS 1.3 that scare me. :-)

> Currently, the post-handshake client authentication does not cause updates
> to the transcript, and does not necessarily trigger key updates. As a
> result, the post-handshake client authentication offers substantially lower
> guarantees *for the client* than the normal mutual authentication. To see
> why this is the case, consider the following two properties that hold for
> the mutually authenticated handshake:
> 
> (A) After the mutually authenticated handshake, a client who sends some
> data can be sure that if the server receives it, the server will be aware
> that it comes from an authenticated client.

AFAICT, this fails even for TLS 1.3 in-handshake authentication.

> (B) After the mutually authenticated handshake, a client who receives some
> data can be sure that when the server sent it, the server was aware that it
> was sending it to an authenticated client. (Formally: upon receiving data,
> the client has agreement with the server on the status (unilateral/mutual)
> of the connection.)

And this too (failure of (A) already impiles this fails).

> However, this is not the case for a post-handshake client authentication.
> After performing a post-handshake authentication (in which the client sends
> its certificate), and possibly after exchanging further messages with the
> server, the client may send some critical data. This data may be stored
> insecurely as there will be a mismatch between the client and server’s
> respective views of authentication if the post-handshake authentication
> messages are not processed by the server and/or dropped by an attacker.

In TLS, the messages can't be dropped without tearing the entiere client-
server link, but the server may indeed fail to process them.

DTLS is another can of worms.
 
> Option 1: Fix
> 
> In our view, the unilateral/mutual authentication status should be part of
> the context, and thus correspond to different keys. We are aware that the
> server’s request for post-handshake authentication is desired to be
> asynchronous (since user input might be needed). The most natural fix to
> the problem therefore is to include the client's response authentication
> messages (certificate etc.) in the message transcript, and require key
> updates.

This would require ACK/NAK for the authentication and restricting server
to just one pending authentication in order to properly serialize the
message order.

And ACK/NAK is needed because otherwise this AFAICT won't solve the
problem. And if you have the ACK/NAK, that should take care of the
problem in cases not involving weak algorithms.

> Option 2: Partial fix
> 
> It is also possible to simply update the keys, leaving the transcript as
> is. This allows the client to infer whether his authentication message was
> received. However it does still allow for re-ordering of some messages.
> This has the disadvantage that the client certificate is still not included
> in the context, which may be problematic further down the line.

I don't see how this helps: The client already knows its authentication
block was delivered before any further data it sent. What it doesn't know
is if the server acted on it.
 
> Option 3: Don’t fix (“Somebody Else’s Problem shield”)
> 
> If we do not change the protocol, the draft should be updated to explicitly
> state that after a post-handshake authentication, the client can make no
> assumptions on the authentication status of the connection (mutual or
> unilateral). If the client would like to know the perceived status, it
> could ask the application layer. We do not advocate this solution, since
> the resulting difference between the guarantees of a regular mutually
> authenticated handshake and a post-handshake client authentication will
> surely lead to problems somewhere, and client applications will wrongly
> assume that after they send the post-handshake certificate, the server is
> aware that the connection is mutually authenticated.

AFICT, This isn't just for post-handshake authentication. And also, the
TLS stack has pretty limited view. It can't realistically assumed to
know the actual authentication status of the connection.


-Ilari