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

Ilari Liusvaara <> Thu, 14 May 2015 05:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 819CF1B33B7 for <>; Wed, 13 May 2015 22:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ygO-SeM4ZftS for <>; Wed, 13 May 2015 22:59:33 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 957E31B33B0 for <>; Wed, 13 May 2015 22:59:32 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id DB5CD818AA; Thu, 14 May 2015 08:59:29 +0300 (EEST)
Date: Thu, 14 May 2015 08:59:29 +0300
From: Ilari Liusvaara <>
To: Nico Williams <>
Message-ID: <20150514055929.GA27098@LK-Perkele-VII>
References: <> <20150412165542.GA19481@LK-Perkele-VII> <20150513222927.GZ7287@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20150513222927.GZ7287@localhost>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] 0-RTT (Was: Re: 0-RTT and Anti-Replay)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 May 2015 05:59:42 -0000

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


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

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