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

[Eric Rescorla <[e-mail]>]

On Wed, Nov 19, 2014 at 12:51 PM, Nico Williams <[e-mail]>
wrote:

> On Wed, Nov 19, 2014 at 11:23:16AM -0800, Eric Rescorla wrote:
> > On Tue, Nov 18, 2014 at 4:45 PM, Nico Williams <[e-mail]>
> > wrote:
> > > > 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?  [...]
> >
> > 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 [...]
>
> Certainly in the resumption case.


Also in the semi-static DHE cases.



> However, in other cases, we'd have to
> have ensure that whatever oob method is used for establishing the
> server's public key also conveys this (e.g., we'd need an RR type for
> indicating this for DANE).


I don't see that that's a problem. At present DANE doesn't contain enough
information for the client to generate a 0-RTT handshake at all, so as
a practical matter we would need to extend the record format, so that
would implicitly agree to 0-RTT (or explicitly if you prefer).



>   It's much easier to have the server hold the
> early data and have it bound into the client's next handshake msg.


This is not generically possible, because the client may have used
a key that the server has forgotten, which requires the client to
retransmit.


> 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.
>
> Yes, of course.  With TLS 1.2 one can renego.  Unless I missed
> something, there's nothing in 1.3 for protecting the client's ID.
>

In TLS 1.3, the client's second flight is sent encrypted. If it were sent
as part of the first flight, it would also be sent encrypted.

-Ekr