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

Roland Zink <> Mon, 23 March 2015 14:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B4E7F1A8ABF for <>; Mon, 23 Mar 2015 07:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PxBizhU85I_q for <>; Mon, 23 Mar 2015 07:05:02 -0700 (PDT)
Received: from ( [IPv6:2a01:238:20a:202:5300::3]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2E281A8AB3 for <>; Mon, 23 Mar 2015 07:05:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427119499; l=1909; s=domk;; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=gogSl4ADhreK6NIGxr+btJ4qwFMUObz36zYnY4eyqUA=; b=yH1R/DsYicFdE+rRF0eF4YmVq2F3exLAPBxrn7IXLn2dNSJq67TTm2yg5daQtNriI95 wouI5Fr6kLvgYoGiRQ/jLljZxJ3d9OjJApfYj5AEJ4y0jrgsEgHMRSdQi5Lsy3ait4p5I GK/w/K6tNt+HAP8JEaA9H8I9w3HXIbiodkg=
Received: from [IPv6:2001:4dd0:ff67:0:b430:a134:91bc:ebfa] ([2001:4dd0:ff67:0:b430:a134:91bc:ebfa]) by (RZmta 37.4 AUTH) with ESMTPSA id R00452r2NE4w5E1 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256)) (Client did not present a certificate) for <>; Mon, 23 Mar 2015 15:04:58 +0100 (CET)
Message-ID: <>
Date: Mon, 23 Mar 2015 15:04:59 +0100
From: Roland Zink <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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:05:03 -0000

On 22.03.2015 22:49, Eric Rescorla wrote:
> There are a number of basic ways to address this issue, but I think
> the main plausible[0] ones are:
> 1. Keep the server state globally consistent and also temporally
>    consistent so that replays can always be detected.
> 2. Remove the TLS anti-replay guarantee for the data sent in the first
>    flight and tell applications to only send data there that can
>    tolerate being replayed.
The server probably can't trust the clients choice. An API on the server 
side is needed as well to check that data received on the first flight 
is acceptable.

> 3. Remove the TLS reliable delivery guarantee for the data sent in
>    the first flight, so that the stack doesn't automatically replay it.
What does happen when the stack can't deliver it? Is the user asked to 
replay? Does the software hang?

> The first of these options (global state) is possible, but only in
> some limited circumstances, namely very sophisticated operators and/or
> situations where there's really only one server which has good state
> management. An example of the latter is WebRTC, where the server can
> have a different anti-replay context for each connection.
> The other two options clearly require a separate API to handle this
> special first-flight data and would require applications to handle it
> separately. So, for instance, in option 2, you would have something
> like:
Does this mean a standard API will be specified. A separate API would 
mean that 0RTT will not be available in many cases because the replay / 
delivery guarantee requirements are unknown in some layers.

The solutions 2 and 3 seem to give the problem to the application, e.g. 
either the application doesn't (need to) care or need to implement it. 
So solution 1 seems the way to go although for non single server 
solutions this may be complicated.