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

Daniel Kahn Gillmor <> Sun, 22 March 2015 23:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CC92A1A802D for <>; Sun, 22 Mar 2015 16:24:05 -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 raFpGZcEh1S3 for <>; Sun, 22 Mar 2015 16:24:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AA4A71A802A for <>; Sun, 22 Mar 2015 16:24:03 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 0826DF984; Sun, 22 Mar 2015 19:24:00 -0400 (EDT)
Received: by (Postfix, from userid 1000) id BEE8120092; Sun, 22 Mar 2015 18:23:57 -0500 (CDT)
From: Daniel Kahn Gillmor <>
To: Stephen Checkoway <>, Eric Rescorla <>
In-Reply-To: <>
References: <> <>
User-Agent: Notmuch/0.18.2 ( Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Sun, 22 Mar 2015 18:23:57 -0500
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
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: Sun, 22 Mar 2015 23:24:06 -0000

On Sun 2015-03-22 18:02:05 -0500, Stephen Checkoway wrote:
> None of the options makes me very happy and I'm really concerned that applications and/or implementations will mess this up and it'll lead to a vulnerability.

i share this sentiment.

> If we absolutely must support 0-RTT (and I believe that we do), then I agree with ekr that relaxing reliable delivery of the first-flight data is the least bad choice.

Calling it "unreliable" in the sense that we can't guarantee that it
will get through sounds likely to mislead users.  In fact, the
"unreliability" is that we don't know whether the data was accepted and
processed by the remote server or not (particularly, in the case of a
distributed service, which the client probably can't distinguish).

So in practice, the data sent in the first flight needs to be seen as
"replayable" in some sense.  If it is rejected by the server but the
handshake continues, then the client has three options as it crafts its
1-rtt reply:

 0) send the same payload again
 1) send some different payload (with the same semantics)
 2) send some different payload with different semantics
 3) abort the connection and surface the error to the user

in cases 0 and 1, the first 0rtt payload could actually still be
processed by some other server, and the client would never know about
it.  So case 0 is strictly "replayable" (as in, the attacker can cause
the same payload to take effect twice) and case 1 is "semantically

I'm having trouble getting my head around any cases that fall into
case 2, and case 3 is what ekr called "implausible".

so "replayable" still seems like the right way to declare this flight to
users, even though it sounds worse than "unreliable".

> I'm not sure how in-scope API recommendations are, but I think that first flight data absolutely needs to be an explicit API call. That is, something like
>     c = new TLSConnection(...)
>     c.write(data)
> SHOULD NOT send data along with the handshake. Ekr's setUnreliable0RTTData really seems like the way to go.

  c = new TLSConnection(replayableData,...)
  if c.replayableDataSucceeded :

I think there are lots of ways that developers can get burned here.
Even testing these codepaths is tricky.