at, Jonathan Hoyland,
Sam Scott, and Thyla van der Merwe.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
oun...@ietf.org] *On Behalf Of *Sam Scott
*Sent:* Friday, February 10, 2017 12:53 PM
*To:* Eric Rescorla
*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 Ekr,
That's a
the client's second flight (0.5 RTT
data). See:
https://tlswg.github.io/tls13-spec/#protocol-overview
<https://tlswg.github.io/tls13-spec/#protocol-overview>
On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott <mailto:sam.scot...@gmail.com>> wrote:
Hi Ilari,
Thanks for the
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
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
between
connections. We are currently working towards a Tamarin proof that PR#316
indeed prevents our attack.
Therefore we would like to support the inclusion of Finished as
part of the handshake context, in order to address this problem.
Many thanks,
Sam Scott
[1] Cas Cremers, Marko Horvat - Univ
