Re: [TLS] Simple, secure 0-RTT for the masses

[Bill Cox <[e-mail]>]

On Wed, Mar 16, 2016 at 5:12 AM, Colm MacCárthaigh <[e-mail]>
wrote:

> On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara <[e-mail]
> > wrote:
>
>> > Benefits Forward Secrecy and Idempotence:
>> >
>> > * Client and server should erase the existing ticket upon use.
>> >
>> > (a captured early data section is mooted for replay quite quickly in the
>> > default "good" case)
>>
>> The best that can be done w.r.t. "forward secrecy" is to erase the
>> decryption-capable key used for 0-RTT on both sides, and never sending
>> it on the wire, even encrypted.
>>
>
> That's why I favor resuming connections where they left off, and cranking
> a PRF to generate new keys; but it's not compatible with tickets at all -
> works only with some kind of session store.
>

We can emulate resumption where we left off with the new ticket extension,
as I try to do above in my "second attempt".  Clearly this requires very
careful implementation, or you would not have so easily broken my first
attempt on this thread.  This is why I think we should document it, and
encourage people to analyze its security properties very carefully.

If emulation of 0-RTT resumption from where we left off is found to be as
secure as 0-RTT resumption from a cache with all the prior connection
state, then I prefer the new ticket scheme because it also supports the
riskier stateless forms of 0-RTT, which can improve speed, resumption
success rates, and lower costs (QUIC does all three).

I would love to see careful cryptanalysis of what we feel is the simplest
secure 0-RTT mode we can offer with TLS 1.3 as it is today.

One thing that helps me with analysis that I do not think is clear from the
spec: the client MUST save the entire session state to do PSK resumption,
other than:

- the previous session secrets which should be erased and replaced with the
resumption master secret
- the TLS sequence numbers since the keys changed.

Is this accurate?  I think it is important for security analysis.

Bill