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