Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)

[Ilari Liusvaara <[e-mail]>]

On Mon, Apr 13, 2015 at 12:57:51PM -0700, Martin Thomson wrote:
> On 13 April 2015 at 12:46, Ilari Liusvaara <[e-mail]> wrote:
> > On Mon, Apr 13, 2015 at 12:30:04PM -0700, Martin Thomson wrote:
> >>
> >> You assume that 0-RTT doesn't fall into that third category.  I hadn't.
> >
> > Well, the only examples of 3) I can come up with would be
> > - Resumption-only (fail enteriely if not resumable)
> > - Something possibly triggering some new type (neither 1RTT, 2RTT
> >   nor abbrevated) of handshake.
> >
> > Of course, I then have trouble even thinking what such new type
> > of handshake could be.
> 
> Well, 0-RTT could be a third category.  As Hugo originally proposed
> it, this would have the authentication of the connection be based on
> successfully proving the ability to generate g^xy.  That's stronger
> than resumption, but relies on the authentication of a previous
> session in the same way that resumption does.  You might consider that
> to be resumption, or not.

I don't consider that to be resumption, since asymmetric crypto is
involved (the whole point of resumption is to avoid asymmetric
crypto).

And furthermore, I don't think it is worth the trouble to introduce
a different kind of handshake for 0RTT case.


I think the idea was (for non-resumption) to derive the 0RTT key from
DH result of client exchange key[1] (possibly with PSK) and cached medium-
term server key.

For resumption, one could derive the 0RTT key from resumption PMS.

The trouble with actual session resumption attempts comes from the fact
that these derive different keys (and at least in threat models I use,
one can't assume key wrapping works).


[1] To prevent that "replay and connect" attack mentioned previously,
either this has to be the actual client exchange key (there can be only
one), key exchange gets complicated since there is now a conditional
input or server can't roll its keys properly.



-Ilari