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

[Colm MacCárthaigh <[e-mail]>]

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. 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?  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