Re: [TLS] 0RTT?

[Martin Thomson <[e-mail]>]

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.

On Aug 3, 2014 10:09 AM, "Watson Ladd" <[e-mail]> wrote:
>
> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls