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

Ilari Liusvaara <> Mon, 06 April 2015 12:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5AAD61A8839 for <>; Mon, 6 Apr 2015 05:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LivZIoqPFc-r for <>; Mon, 6 Apr 2015 05:05:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A66C1A8838 for <>; Mon, 6 Apr 2015 05:05:57 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 6BF0C81811; Mon, 6 Apr 2015 15:05:54 +0300 (EEST)
Date: Mon, 6 Apr 2015 15:05:54 +0300
From: Ilari Liusvaara <>
To: Eric Rescorla <>
Message-ID: <20150406120554.GA23058@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Archived-At: <>
Cc: "" <>
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, 06 Apr 2015 12:06:01 -0000

On Sun, Mar 22, 2015 at 02:49:28PM -0700, Eric Rescorla wrote:
> In the interim in Seattle, we had an extensive discussion of 0-RTT
> anti-replay in which DKG observed that all the proposed anti-replay
> mechanisms provide limited protection. The underlying problem is the
> desire to present a uniform interface in which the calling application
> can count on reliable delivery of the data it provides in the first
> flight, thus requiring the TLS stack to retransmit it automatically.

> 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:
>     c = new TLSConnection(...)
>     c.setReplayable0RTTData("GET /....")
>     c.connect();

This is on client side, but how about server side?


- Server app indicates to TLS stack if it supports 0RTT.
- If no support or 0RTT fails, 0RTT is refused and retransmitted
  data is prefixed into connection data.
- If supported and 0RTT transmission succeeds, app can read 0RTT
  data using separate call.

Problem: 0RTT supported but failing (e.g. wrong keys) is a special
case for serverside.


- Server app indicates to TLS stack if it supports 0RTT.
- If no support, this is signaled to client.
- If supported but fails, this is signaled to client.
- 0RTT data (original or retransmit) is read using separate

Problems: 0RTT supported/not supported is two different cases
for the client. Retransmit would need to be flagged specially.


- If 0RTT fails or not supported, it is refused.
- Just prefix 0RTT data into connection data.

Prolem: Server can't tell apart 0RTT data from normal data.

Also, regarding security considerations due to replayability, would
"MUST NOT authenticate in 0RTT data" (which e.g. means cookies that are
possibly authenticating can't be sent)  be useful consideration?