On Thu, Feb 25, 2016 at 9:55 PM, Antoine Delignat-Lavaud < [email protected]> wrote:
> 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. > Yes, that's correct. > 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). > My thought of how to deal with this was to simply *infer* the 0-RTT parameters from those when the PSK was established. This is the natural extension of what the document currently says about DHE-0RTT but can be simpler because the ticket can contain the full state. -Ekr > Best, > > Antoine > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
