Re: [TLS] 0-RTT security considerations (was OPTLS)

[Eric Rescorla <[e-mail]>]

On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams <[e-mail]>
wrote:

> On Tue, Nov 18, 2014 at 04:04:10PM -0800, Eric Rescorla wrote:
> > On Tue, Nov 18, 2014 at 3:46 PM, Nico Williams <[e-mail]>
> > wrote:
> > >  - Replay protection (use replay cache or defer protection)
> > >    [...]
> >
> > Yes, I agree that this doesn't make sense. The server needs to provide
> > anti-replay as part of the TLS stack using some sort of server-side
> state.
> > Servers which don't want to do that should not offer 0-RTT.
>
> But how would the client know the first time?  Perhaps it shouldn't
> matter.  The server should just hold back before delivering the data.
> Still, in order to do this without a replay cache the handshake has to
> have two more messages after the one where the client is prot_ready and
> the client has to confirm the early messages.  So this has to be part of
> the protocol.


I'm not following. The idea here is that the server indicates to the
client that it is in principle prepared to do 0-RTT and provides a key
that can be used for that. If the client attempts it and it doesn't work
out (e.g., because the server has lost the key), you fall back to a
1-RTT handshake, so the server can just discard the data rather
than holding it.



> >  - Client authentication state
> > >
> > >    Imagine a handshake where the client is not authenticated until the
> > >    second round trip, but we have key material for 0-RTT.  The server
> > >    cannot authorize any application protocol commands at this stage
> >
> > Every proposal I have ever seen for 0-RTT has the client delivering
> > client auth in the first flight for exactly this reason.
>
> Even ones where the client is afforded confidentiality for its ID? I

can certainly imagine protocols where that wouldn't be the case.


If you can send encrypted data to the server, you can also
encrypt the client's certificate. Yes, it's possible to design protocols
where that doesn't work, but it's also possible to design ones where
it does.


>  - Symmetric session key non-reuse depends entirely on the client and
> > >    its RNG.  E.g., in the resumption and PSK cases.
> > >
> > >    When using cipher modes where key/IV reuse is disastrous this could
> > >    be a serious problem.
> > >
> >
> > The conventional way to address this (as in snap start) is to use an
> > anti-replay mechanism which ensures uniqueness of the client random,
> > thus providing key uniqueness.
>
> By the time the server can check this it's too late: the client sent the
> bad ciphertext.


Good point. I agree that the client needs a strong PRNG.

-Ekr