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-boun...@ietf.org] On Behalf Of Sam Scott
Sent: Friday, February 10, 2017 11:46 AM
To: Ilari Liusvaara <ilariliusva...@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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
