Re: [TLS] 0-RTT and Anti-Replay

Viktor Dukhovni <> Mon, 23 March 2015 14:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CFC561A8AFA for <>; Mon, 23 Mar 2015 07:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 63NYu-Djej5z for <>; Mon, 23 Mar 2015 07:40:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A1891A8AF8 for <>; Mon, 23 Mar 2015 07:40:54 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 95324283011; Mon, 23 Mar 2015 14:40:52 +0000 (UTC)
Date: Mon, 23 Mar 2015 14:40:52 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <20150323083308.GL21267@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150323083308.GL21267@localhost>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [TLS] 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: Mon, 23 Mar 2015 14:40:57 -0000

On Mon, Mar 23, 2015 at 03:33:09AM -0500, Nico Williams wrote:

> On Sun, Mar 22, 2015 at 08:35:34PM -0700, Martin Thomson wrote:
> > For HTTP, I think we can use that first flight for idempotent queries
> > quite easily and (at worst) the HTTP/2 connection preface.
> But TLS can't know what's happening at the application layer, so it had
> better be the case that the 0-RTT data is clearly denoted to the app as
> "had better be idempotent".  I.e., this becomes an API issue.  The name
> of the method would have to be indicative of danger.
> 0-RTT data is acted on at great risk.  It's OK to use it for negotiation
> purposes where the integrity of the negotiation will eventually be
> confirmed (else the connection fails).  For things like "launch
> missiles" it is a very bad idea to act on the command before
> authenticating it and determining that it's not a replay.  When we don't
> know the nature of the data, we must assume it can't be sent without
> authentication and replay protection.

Therefore, 0-RTT data must:

    * Require a non-default code path to send, (explicit request
    by the client to send a 0-RTT message).

    * Require a non-default code path to *receive*.  That is,
      the server must be configured to allow receipt of such data,
      and must explicitly request to read it.  If the server issues
      a read for protected data, while expedited 0-RTT data is
      pending, the connection should be aborted by the server's
      TLS stack.  Once the server exhausts all the expedited
      data, it can switch to reading protected data.

    * The server's TLS stack must not coallesce 0-RTT expedited
      (idempotent) data with subsequent protected data.

This allows servers that receive idempotent queries to avoid the
1-RTT latency.  Something akin to DNS lookups over TLS, (I am not
specifically advocating TLS as a transport for DNS in this message).

Servers reading expedited 0-RTT data will be aware that they are
doing that, and can/should reject operations that are unsafe in
that context.

This avoids all futile attempts to add stateful replay protection
to a stateless phase protocol.  I expect such attempts are doomed
to failure.