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

[Ilari Liusvaara <[e-mail]>]

On Tue, Apr 14, 2015 at 08:46:06AM +0300, Ilari Liusvaara wrote:
> 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).

Well, the question is really where the keying material for encrypting/
decrypting 0-RTT is obtained. There are three obvious candidates:

1) (x*S_old = s_old*X, ClientRandom)
2) (rPMS, ClientRandom)
3) (PSK, ClientRandom)


[(x*S=s*X, ClientRandom) and (x*S_new=s_new*X, ClientRandom) do not
work, the first is mathematically ill-defined, and the second
is uncomputable for client]

Each is obvious candidate to one server key exchange type:
1) for full DHE handshake.
2) for abbrevated handshake.
3) for full pure-PSK handshake.

However, no other combination works well, either because it makes
the server sad, or the server doesn't have the needed keys. Unifying
abbrevated and pure-PSK handshakes doesn't help much here (since
keys presumably won't match).


Now, the real issue:
Suppose that client is willing to accept multiple of the three key
exchange types (full-DHE, abbrevated and pure-PSK) at once. Now,
all three are expected to use different keys. Under what keys does
client encipher the 0RTT data?

Indirect keying (key wrapping) leads to "interesting" security
analysis, as inner encryption effectively becomes unauthenticated.


(Also, the used 0-RTT key, if any has to be mixed in with appMS
to prevent an attack).


-Ilari