Re: [TLS] 0.5 RTT

On Thu, Feb 25, 2016 at 9:55 PM, Antoine Delignat-Lavaud <
antoine@delignat-lavaud.fr> wrote:

> Le 2016-02-25 12:29, mrex@sap.com 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>