Le 2016-02-25 12:29, [email protected] a écrit :
Karthikeyan Bhargavan wrote:
Yes Hugo, you?re right that when there is no client auth,
the situation is less problematic.
I'm not so sure.
QUIC gives a pretty good idea of how 0-RTT is going to be used in
browsers: they will almost certainly send 0-RTT requests that contain
session cookies and servers will return confidential data in 0.5-RTT
routinely. I think it is very important to assume that this usage
scenario is part of the core features of 1.3 that we model and analyze.
There is little doubt that 0.5-RTT will leak some bits of information
due to replayability; nevertheless, assuming that 0.5-RTT data is always
public and give it the same guarantees as handshake encryption is a bad
way to deal with these problems.
Under the current key schedule, an active adversary still needs to break
the PSK in order to decrypt 0.5-RTT data; this is a forward secrecy
problem rather than a confidentiality one.
Even if the 0-RTT finished message is removed, the context of the 0-RTT
data key will still include the current ClientHello, and thus, downgrade
in the style of Logjam+False Start requires PSK compromise as well.
Concerning agility, a simple strategy is to pre-negotiate 0-RTT
handshake parameters (including ciphersuite) when the PSK is established
(i.e. extend the NewSessionTicket message).
Best,
Antoine
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
