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

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 13 May 2015 23:58:17 +0300

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 <[email-masked]> 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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 May 2015 14:18:59 -0700

> client encipher the 0RTT data?

Why wouldn't the client just choose and signal the option they chose?

BTW, it has been suggested that there might need to be some material
from the server contributed to this mix to prevent an unknown key
share attack.  So secret[x] + ClientRandom is not quite sufficient.

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 May 2015 17:29:29 -0500

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 14 May 2015 08:59:29 +0300

> question of "have we seen this before", but also, "have we processed

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

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

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

> replay caches have to protect, at least for session resumption 0-RTT

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

> >     info about what's in 0-RTT blob)? Or not?

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

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 14 May 2015 09:08:59 +0300

> Why wouldn't the client just choose and signal the option they chose?

Just one allowed, or multiple (server picks one)? :-)
 
> share attack.  So secret[x] + ClientRandom is not quite sufficient.

Any specifics?

Is this somehow related to attack that arises if client does not do
Proof-of-Possession of the 0-RTT key[1]?

[1] AFAIK, one way to do that PoP is to mix the key (or closely
related value) into appMS if 0-RTT is accepted.

-Ilari