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

[Nico Williams <[e-mail]>]

On Thu, Nov 20, 2014 at 09:06:21AM -0800, Eric Rescorla wrote:
> On Wed, Nov 19, 2014 at 12:51 PM, Nico Williams <[e-mail]>
> wrote:
> 
> > Certainly in the resumption case.
> 
> Also in the semi-static DHE cases.

Yes, of course (it's like resumption in a way).

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

My inclination is to think that adding a new RR type or extending TLSA
for this is not worthwhile.  See below.

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

Yes, indeed.  Applications that can retransmit, could do that.  For
other applications (which is to say: most) the result has to be failure,
and then a reconnect.  Not good.  This is a good reason to want to
minimize 0-RTT usage to cases where the client has good reason to think
the server will be able to handle it: when a) the server said or
advertised so earlier, b) not much time has passed since.

0-RTT is an optimization, but if it can lead to failures that
applications must special-case, then that's problematic.  For HTTPS
that's probably not a problem (it's just one reconnect).

Will 1.3 support 0-RTT?

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

So... is confidentiality protection of the client's cert/ID explicitly
supported in 1.3?  That'd be great news.

Nico
--