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

Andrey Jivsov <> Mon, 23 March 2015 03:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 914471A87AF for <>; Sun, 22 Mar 2015 20:48:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JC5ucGWEt_M9 for <>; Sun, 22 Mar 2015 20:48:15 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9D1F1A87BB for <>; Sun, 22 Mar 2015 20:48:15 -0700 (PDT)
Received: from ([]) by with comcast id 6roF1q0025AAYLo01roFHZ; Mon, 23 Mar 2015 03:48:15 +0000
Received: from [] ([]) by with comcast id 6roE1q00F4uhcbK01roE63; Mon, 23 Mar 2015 03:48:15 +0000
Message-ID: <>
Date: Sun, 22 Mar 2015 20:48:14 -0700
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Martin Thomson <>, Eric Rescorla <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1427082495; bh=DWxQMOEvI5papH6QYTjtDF87vqLOwjzJIrt7T75Pl74=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DTpCPnsDKbi5Ic/p/i0MD+By1OE3F0W4QokaB2w1vI78CO+gQ8ZTsMVtXffiha8W9 WXxubxJIB65gRC/bRB7ix8+QKAhCu2VCj9XEsS9jQtqaCzgAT1aL7/VKq9+CSkNgCO J6xjMiGCKgvWo/pxUDHo9tcMlzQEE9G2FXxgMW+d1ZVC4cj7s3V/i2HUiQ+Mtr4Nbg EEzknRM7eXzONrOWum59jE+C1c4QoZ/34Ady/40EFe7IuvOTEXbl5MNH37u5YwNiaj hfAsEPZu4Hxbp4c+I8Qkm1vx6+KFyHx0CT7FhEuIeO/XuVnCS5j/YJRpRvd/8MMSCM P2hnYGRhbsZaQ==
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, 23 Mar 2015 03:48:17 -0000

On 03/22/2015 08:35 PM, Martin Thomson wrote:
> On 22 March 2015 at 20:19, Eric Rescorla <>; wrote:
>>> One way to solve this is to say that the server must *fail* 0-RTT, as
>>> opposed to fallback to 1-RTT, if the "orbit" indicated in the ClientHello is
>>> not that of this server.
>> Yeah, this is what I claimed is "implausible" in my original message.
>> My concern here is that this basically means that implementations get
>> punished with random failures for any data center/routing instabilities...
> I don't see any way that we can support a mode that fails with
> increased probability like this.  I think that the only real options
> here are #2 and #3.  I'm tending toward a requirement for marking the
> data as being explicitly replayable, simply because I don't think we
> should leave applications with the awkward choice of deciding between
> resend and something else.  Mainly because I don't know what that
> something else looks like.
> For HTTP, I think we can use that first flight for idempotent queries
> quite easily and (at worst) the HTTP/2 connection preface.

I was thinking about in terms of two websites from different companies A 
and B.  They are independent and they get different orbit IDs. If A sees 
an orbit ID of B that A would never have sent, this is a replay. An 
error is appropriate on such mismatch.

Likewise, A, B can be divisions in the same company, in which case, 
again, there are different Orbit IDs and an error on mismatch.

When A and B are load-balanced, e.g. by DNS entries, then A, B are in 
the same orbit. In this case they should use the same DB.

(I probably re-defined the "orbit". In my proposal it's a persistent ID 
that survives the reboot ).

If the data center is misconfigured or a client confused the origin of 
the 0-RTT state, isn't an error appropriate? Otherwise, yes, there would 
need to be restrictions on data sent in 0-RTT.