Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

[Eric Rescorla <[e-mail]>]

On Fri, Mar 25, 2016 at 12:23 PM, Colm MacCárthaigh <[e-mail]>
wrote:

> On Fri, Mar 25, 2016 at 11:36 AM, Eric Rescorla <[e-mail]> wrote:
>
>> On Fri, Mar 25, 2016 at 11:27 AM, Colm MacCárthaigh <[e-mail]>
>> wrote:
>>>
>>> +1 but I think we can go further here and specify 0RTT in such a way
>>> that it only works when the server maintains state, and so that any given
>>> 0RTT ticket may only be used once (to preserve forward secrecy as much as
>>> possible within the constrains of 0RTT).
>>>
>>
>> I'm not enthusiastic about this. This seems like it would rule out a
>> bunch of implementations
>> which don't need that guarantee.
>>
>
> With 0RTT, it doesn't seem to be possible to have anti-replay of the
> message itself without some kind of server state.
>

Yes.



> It's also beneficial for cryptographic safety to prevent at-will re-use of
> the ticket - other-wise the data is subject to the kind of "try and
> iterate" attacks we've seen be very successful against DTLS because of its
> tolerance for duplicate and out of order messages. If server state is
> required, some more good can come of it by improving the forward secrecy of
> the 0RTT data to match that of regular data; which I think is most
> important of all.
>
> An implementation would have to be willing to sacrifice replay protection,
> some cryptographic safety and forward secrecy for the 0RTT data. I'm sure
> there are implementations that would sacrifice these things to get lower
> latency more cheaply, but should they be encouraged?
>

The issue isn't encouraged. It's whether we should design the protocol so
that it cannot be implemented any other way.

-Ekr


>   I'll admit that this is an unfair simplification in this case since it's
> a more grey area, but "fast, secure, cheap: pick two" is at play here, and
> many would pick "fast, cheap".
>
>
> --
> Colm
>