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

[Nico Williams <[e-mail]>]

On Sun, Apr 12, 2015 at 07:55:42PM +0300, Ilari Liusvaara wrote:
> I thought about 0-RTT some more, here are some questions. Few
> might be protocol-relevant, most are only about guidance.
> 
> 1) What is the recommended 0-RTT API model on server side
>    (also consider server apps or app implementations that don't
>    support 0-RTT)?

The app should request 0-RTT data; server should drop it if not
requested before receipt of ClientHello.

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

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

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

> 5) There is potential footgun if 0-RTT is used with (DH-)PSK: The
>    PSK authenticates the connection immediately, but 0-RTT is
>    as replayable as ever. What to do with that?

0-RTT is a footgun.  Choice of ciphersuite seems a bit beside the point,
though it's possible that positive authentication status of the client
may cause applications to fire the footgun.  I'd insist on the
authentication status not being complete until the handshake completes
in all cases, and I'd insist on pointing out that the 0-RTT data is a
lot of rope.

> 6) The same as above, but when attempting to resume a session.
>    with a client certificate (since cc is property of session)?

Ditto.

> 7) What guidance to give regarding what data can be put to 0-RTT,
>    considering its replayability?

First, that it's replayable.  Second, that the application should only
send such data where doing so is idempotent, or where it is part of
something like an application-layer authentication protocol that will do
its own replay protection, or where the application has its own replay
detection cache.

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

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

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

Nico
--