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

[Ilari Liusvaara <[e-mail]>]

On Wed, May 13, 2015 at 05:29:29PM -0500, Nico Williams wrote:
> On Sun, Apr 12, 2015 at 07:55:42PM +0300, Ilari Liusvaara wrote:
> 
> > 2) What are the semantics of successfully received 0-RTT transfer
> >    (especially considering the client-side autoretransmit on
> >    failure)?
> 
> Leave it to the app.  A replay cache option would be nice, but the app
> probably needs to provide this itself (since, after all, it's not just a
> question of "have we seen this before", but also, "have we processed
> this before").

If 0-RTT fails, client's first reaction is probably to replay the failed
0-RTT data, or something equivalent to it...

> > 3) How does 0-RTT interact with ALPN (especially considering
> >    potential for multiple protocol candidates)?
> 
> The client has committed to an application protocol.
> 
> Although that's not necessarily quite so true: elsewhere we're talking
> about an RFC2712 (Kerberos in TLS) replacement where ideally we could
> start sending GSS-API context tokens as early as possible (when the
> client doesn't want confidentiality protection for its name).  Such a
> protocol could still negotiate from N>1 application protocols.
> 
> (GSS-in-TLS as an application protocol using 0-RTT data is a perfect
> example of a *safe* use of 0-RTT data, provided that the intention is to
> also do channel binding.  Don't think about GSS too hard here.  Just
> think about the point that some 0-RTT uses will be quite safe.)

So consideration that only put compatible ALPN IDs (that could lead
to connection failures, due to incomplete set)?
 
> > 4) Can handshake with attempted 0-RTT be securely downgraded to
> >    v1.2 (obviously causes the 0-RTT to fail)?
> 
> Sure, but the 0-RTT data must get dropped.

Actually, thinking about it, ability to tolerate downgrade (losing
0-RTT) isn't that important if one has already to restrict ALPN.

> > 8) If resumption attempt has 0-RTT data, what keying material is
> >    used for the 0-RTT?
> 
> In principle, none.  However, a key derived from the resumption ticket's
> session key would be nice.  See below.
> 
> The PSK case could be similar as well.

Well, None means unencrypted? :-)

And yes, resumption ticket / PSK key would be nice, saves server
quite expensive asymmetric-key operation.

> > 9) Can server roll over its 0-RTT keys without waiting for the
> >    previous ones to expire?
> 
> In relation to (8)?  No.  But we could do something where we use
> timestamps, a la Kerberos, to greatly reduce the time window that any
> replay caches have to protect, at least for session resumption 0-RTT
> data!

I mean server doing full (DH) handshake, accepting 0-RTT and signaling
new 0-RTT keys for future connections in the same connection.

(Obviously if session keys are used, the 0-RTT keys expire with the
session context).

I.e.

C->S: [full DH, 0-RTT data: encrypted using x*S_0, (kid k_0)]
S->C: [0-RTT accepted]
S->C: [new 0-RTT key S_1 (kid k_1), expected valid until T_1]
S->C: [Handshake complete]

(In "DH-based" key exchange, it is undefined behaviour for server
to attempt that, since it makes no distinction between old and new
key).

> > 10) How is attacker establishing a session (or at least decoding
> >     server's first application flight) replaying captured
> >     0-RTT data prevented (since that could leak quite a bit of
> >     info about what's in 0-RTT blob)? Or not?
> 
> IIUC, it isn't.

AFAIK, if 0-RTT is accepted, hashing in 0-RTT keys (or closely
related values) should take care of that.


-Ilari