Subject: [TLS] 0RTT?

From: Watson Ladd <[email-masked]>
Date: Sun, 3 Aug 2014 10:09:01 -0700

Dear all,

I think I came up with a decent idea for handling 0RTT handshakes,
namely making resumption 0RTT, and doing a side rekeying.

To see this work we assume that the usual resumption ticket gets set
in the handshake, and determines the PMS. A resumption looks as
follows:

-The ticket
-An anti-replay nonce: BLAH bytes
-A refresh key: since we know what the server wants, we can provide a
group it supports

The PMS that gets used is PMS_interim= HMAC(old_PMS, nonce || refresh
key): data encrypted as usual under the old ciphersuite follows. (Note
that we may have to include the entire Client Hello hashed: this is
probably easier, except that the data goes in the Client Hello when
using the current inclusion mechanism)

On receiving this a server looks up the anti-replay nonce and checks
it is fresh. To make this easier we include UTC time since the epoch (
midnight of 1 January 1970) and mandate some degree of synchronization
and a window. To avoid tagging with clock drift we truncate some low
order bits after adding a random small offset.

If the nonce is not previously seem the server can send Application
Data as normal.

We now introduce a new handshake type: Rekey Finish, containing a new
ticket and server key. CCS follows afterwards. These are sent
encrypted.

The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)).

The big limitation is ticket keys are going to need rotation. This
also doesn't address the desire to put extra data in DNS to give some
degree of forward secrecy, but I don't think you can change DNS that
quickly without some problems.

Furthermore, if we want rekeys without renegotiation, we can reuse
Rekey Finish and add a Rekey Initiate handshake type that will send
the client key.

Open questions: how secure is this? We certainly need to hash the
anti-replay nonce into the keys: is that all we need? (Not if we want
to avoid attackers manipulating which method we use) Does noisy
truncation work to prevent fingerprinting while reducing storage
requirements?

Sincerely,
Watson Ladd

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sun, 3 Aug 2014 13:25:17 -0400

> key): data encrypted as usual under the old ciphersuite follows. 

I guess I don’t understand what this means. Is the new application data encrypted
under (a) the old MS? (b) a new MS derived from PMS_interim (and the old randoms)? 

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Watson Ladd <[email-masked]>
Date: Sun, 3 Aug 2014 10:32:30 -0700

> under (a) the old MS? (b) a new MS derived from PMS_interim (and the old randoms)?

I was thinking new MS.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Martin Thomson <[email-masked]>
Date: Sun, 3 Aug 2014 13:22:05 -0700

This reads a like a halfway between the proposed 0RTT handshake and
resumption.  The advantage here I'm guessing being that this is
resumption, which means that you bind to a specific previous session.

However, I keep hearing that the main benefit of resumption is that it
doesn't require a new DH operation.  And yes, this is still important
even with the higher performance EC provides.

This relies on an old session, whereas the proposed 0RTT uses a DH
share that is essentially public, so that it can be cached and shared
(DNS, signaling).

As far as security goes, I don't see any major issues with this.  The
initial round of application data is going to be as well protected as
the previous session was.  As long as you aren't able to choose a
different cipher suite to what was previously used, and I can't see
why you would want to even contemplate allowing that.

Why do you need a new message?  Since you are using DH, you could just
use the remainder of the 1RTT handshake structure with
ServerKeyExchange.  You could, I suppose eliminate the authentication
messages in order to rely on the previous session.

If the fallback story when the ticket/nonce/share is bad is the
existing regular handshake, then this is quite close to the proposed
0RTT mode.  With a few differences in terms of the first flight keys
are derived and their lifecycle.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 3 Aug 2014 19:43:19 -0700

> even with the higher performance EC provides.

So I was going to make rekey optional. This wasn't very clear in my
original email.

> share that is essentially public, so that it can be cached and shared

That has costs with key rotation and administrative version. Maybe
those aren't so bad. But I would like to see resumption be 0RTT also:
right now it is 2RTT in TLS 1.2.

> why you would want to even contemplate allowing that.

I don't think you are qualified to say that, and the reasoning is
fallacious. You need to mutter something about PRF distinguishing and
collisions, and ideal functionality and simulation. (In particular if
I didn't mix in the old PMS, there would be an attack)

> are derived and their lifecycle.

It probably is, but I think I missed the email where that was
discussed. The design space is constrained enough I think we are
converging on a very similar solution.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Aug 2014 20:10:46 -0700

Watson,

Interesting suggestion.

It does seem like a good idea to allow 0-RTT with resumption, assuming
we retain resumption but I'm not sure we really want to couple resumption
and 0-RTT, since that would mean that there's no way to get 0-RTT first
handshakes even when the server has some out-of-band way of publishing
his key, such as in DNS or WebRTC SDP (this is a real issue for WebRTC,
where we *do* have an out-of-band channel for signaling.)

The basic property of 0-RTT is that the client can share
a key with the server on the first message and that's compatible
with both session resumption and a semi-static server DH key
(See, for instance:
http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-6.3,
figure 5). It should be possible to design a 0-RTT mechanism that
works for both.

Also, I would also suggest that we separate out the exact design of the
anti-replay mechanism from the question of whether 0-RTT and resumption
go together. Generally, these mechanisms have some kind of scoping
mechanism (e.g., a server-provided context string and a timestamp,
as in Snap Start) and then a client-provided nonce. The details seem
like something we can tune separately. It's also worth observing that
if you encrypt the scoping values you can significantly reduce their
privacy exposure, since only the target server gets them.

Best,
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Aug 2014 20:12:34 -0700

> right now it is 2RTT in TLS 1.2.

In TLS 1.2, I believe it's actually 1 RTT from the client's perspective:

      Client                                                Server

      ClientHello                   -------->
                                                       ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished
      [ChangeCipherSpec]
      Finished                      -------->
      Application Data              <------->     Application Data

The client can send data on its second flight.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Aug 2014 10:54:17 -0700

> right now it is 2RTT in TLS 1.2.

One thing I like with your proposal is that it looks a lot like the
0RTT proposal, but with a different key derivation path that avoids
the "expensive" operation.  If the rekeying is optional it diverges
some, but no so badly.

I see the following choices for a server that receives a handshake in this form:

a. Regarding the data, the server can accept the data or not

b. Regarding the keying material, the server can continue to use the
indicated "master secret", or it can request that a new DH exchange be
completed

   **  Here we could also enable other options, like having the server
offer a backwards reference for authentication, or maybe you can
renegotiated ciphersuite...  I think that would be unnecessary
complexity; if you continue based on the previous session, then I'd
prefer not allowing anything to change about the session; if you want
to change anything, the server can re-run a full handshake.

I think that the choice regarding the data is largely orthogonal to
the choice regarding the keying material.  These seem to be the most
relevant choices:

1. accept the data and keys, continue with the provided keys
2. reject the data, but continue with the provided keys
3. accept the data, but re-run the handshake
4. reject the data and re-run the handshake

The two options being what is new here.  The proposed 0RTT mode allows
the latter options only.  The case where the server rejects the data
is a little odd, but it might be that the server doesn't want to do
nonce-checking; and it is closest to the 1.2 resumption handshake.

---

From: [email-masked] (Martin Rex)
Date: Mon, 4 Aug 2014 23:01:02 +0200 (CEST)

> namely making resumption 0RTT, and doing a side rekeying.

These idea(s) seem to based on a number of extremely optimistic
assumptions that have zero chance to get airborne in many usage
scenarios.

The "regular" TLS session resumption means that client announces
a TLS session ID in ClientHello and server looks up that session ID
in its own cache for a match.  If there is no match, a regular
TLS full handshake proceeds.

0RTT is a no-go for a huge number of existing apps which do not
perform any fancy reconnect fallbacks at the application level
(closing the previous connection, opening a new connection and
starting a new handshake from scratch while requesting different
handshake characteristics this time).  For the general case
a 1RTT resumption is required, which can successfully perform
a full handshake in case that resumption is not possible,
without having to go through a connection/handshake failure.

> quickly without some problems.

The visibility of data DNS is another bold assumption that doesn't
hold for a number of usage scenarios.  It is pretty normal for
company networks to run their own DNS universe internally, and
provide accessibility to servers on the internet only through
HTTP CONNECT proxies.  In general, only these HTTP proxies have
access to both DNS universes (internet and internal).

I remember when Java applets became popular for use with online
brokers ~17 years ago, and lots of these applets crashed and burned
behind HTTP CONNECT proxies.  The browser had no problem connecting,
but the applets choked on hostnames that didn't resolve.  The
workaround was to add the brokers web server hostname with an
arbitrary ipv4 address (1.2.3.4) to the local host file so that
the Java applet would get a(n obviously useless) response
from gethostbyname() and be happy.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Mon, 4 Aug 2014 18:52:30 -0700

> without having to go through a connection/handshake failure.

I think we can handle this by thinking about fallback options more
carefully. Certainly a resend can be done at the implementation level
with the new handshake: this will cost latency, but it can be done.

Sincerely,
Watson Ladd

---

From: [email-masked] (Martin Rex)
Date: Tue, 5 Aug 2014 14:34:13 +0200 (CEST)

Watson Ladd wrote:
> Martin Rex <[email-masked]> wrote:
> > Watson Ladd wrote:
> >>

For 0RTT this option does not exist.  A multi-megabyte HTTP POST on top
of a 0RTT TLS connection would waste lots of resources before even
realizing that there is a problem and the bandwith was completely wasted.

For other TLS extensions, a possibility to restart/reset the ongoing
handshake could be defined so that TLS implementations could adopt
and transparently provide it.

But look at what gets pushed here in TLS WG instead:
  http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00

which is a bogus proposal to panic and close the network connection
on the server side and dump a genuine TLS problem entirely on the
application caller of the clients TLS implementation.

-Martin