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

Hi all,

Thanks Ilari and Andrei for pointing towards the fact that TLS 
guarantees ordering of messages.

On closer inspection, this has a similar effect as our partial fix to 
ensure the server must process the authentication message before continuing.

We still consider the lack of a strict binding by not including the 
client certificate in the transcript to be a slight problem, but this is 
less of an issue than what we first discovered. Our model assumes 
messages can arrive out of order, so perhaps we are instead considering 
a weaker variant, similar to DTLS.

The core observation remains that the context does not change when going 
from unilateral to mutual, which seems counter to the intuition of the 
context. We would prefer the context to also contain the client cert in 
mutual authentication. Indeed, we first encountered this issue when 
considering whether the client/server would agree on the authentication 
status after a session resumption. In this case, the client auth and 
NewSessionTicket messages may cross over which would result in a similar 
mismatch.

Thanks,

Sam

On 10/02/17 19:54, Andrei Popov wrote:
> Hi Sam,
>
> This part is not clear to me:
>> ...while in the post-handshake client auth, an attacker can decide this (by dropping the message).
> How does the attacker drop a TLS-protected message without terminating the connection?
>
> Thanks,
>
> Andrei
>
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sam Scott
> Sent: Friday, February 10, 2017 11:46 AM
> To: Ilari Liusvaara <ilariliusvaara@welho.com>
> Cc: tls@ietf.org
> Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
>
> 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