Re: [TLS] Limiting replay time frame of 0-RTT data

Brian Smith <> Sat, 12 March 2016 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DA6412D804 for <>; Sat, 12 Mar 2016 11:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OZj_x9XFDmra for <>; Sat, 12 Mar 2016 11:33:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 244E812D801 for <>; Sat, 12 Mar 2016 11:33:29 -0800 (PST)
Received: by with SMTP id ts10so143036374obc.1 for <>; Sat, 12 Mar 2016 11:33:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wO7Rut2jb0Ea8iRZ1cipxjXYkJoJ6p9Ix5boUOdICqY=; b=O3/yT68wcO7qL49DQTfTfYdmG2TamLLBd+6QsfQqZYSmpr+1JhQM9KSPjQwkCxQPBZ 2t/9YzemRIAVim4TDa7w2fQw03W5G474VoC5YHzlgaAqnJ/6g70oPPllaUNQW1krKOre pzsZO5EEeT7kmguoWKxNISgWqlj2mArzATvjaOaXtwfCzMJT7nEDiHKXqmda55NCZy35 j6eqwLdBqHXk+VVOt5sUO/6DRePRpHHePJP3qua5ZQwHp7/CkSpPCE6wwo9qq6eq2GYL F1Q/IctEqRa9AgKMkqL5iwM2r/vFU3OtJrO0it7y24rfOxlfHHxp/8xdUJ36ye7cPNlr ofPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wO7Rut2jb0Ea8iRZ1cipxjXYkJoJ6p9Ix5boUOdICqY=; b=kY9iKm1djlTQxTpvgLgMje+QRgN0c4YmrcTJvZMcgMdn5LTB4aaazMdoPLwNYqi7AE rAwUMBTrwDryl3iA99TcnUmSCbK5GGBYfY0d8MgshDEULYymPdYFSy066O4Trp4B5LIp wlxc7LmSFc1k0ogxzcMYn/m5R3+HjpImQthhg581cuWx2GI5up/4x/Rrw9xQ+sE3SYTG pqElsh4XBaCaiKiKg/QsV0KrLDpkQSzOrGSyxmIm4IcNq+Gkk3eQtTfuqkUljYefxB1z TkWvFsLBs9ulqz3YHLDUckGSn6SiXzp3CnTMM2Gd/PsEjU9FxnZ2b8YgY/C1909+pSq0 H4cw==
X-Gm-Message-State: AD7BkJJ87i500RzwqMicA9UnVoZyw8CGmBbhI6+AkdWzt1jaeE5tHlP+41t8MQCXC9QzhXXGo86wYFSB3rCV5w==
MIME-Version: 1.0
X-Received: by with SMTP id np3mr9962369oeb.16.1457811208510; Sat, 12 Mar 2016 11:33:28 -0800 (PST)
Received: by with HTTP; Sat, 12 Mar 2016 11:33:28 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Sat, 12 Mar 2016 09:33:28 -1000
Message-ID: <>
From: Brian Smith <>
To: Kyle Nekritz <>
Content-Type: multipart/alternative; boundary=047d7b417dc73bbbad052ddf1ff9
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Limiting replay time frame of 0-RTT data
X-Mailman-Version: 2.1.17
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: Sat, 12 Mar 2016 19:33:43 -0000

On Fri, Mar 11, 2016 at 10:21 AM, Kyle Nekritz <> wrote:

> Note: it’s also useful for the server to know which edge cluster the early
> data was intended for, however this is already possible in the current
> draft. In ECDHE 0-RTT server configs can be segmented by cluster, and with
> tickets, the server can store cluster information in the opaque ticket.

Shouldn't the server also put a 0-RTT timestamp in the opaque ticket and
then implement the same time limiting you suggest using that timestamp?
That way, the timestamp would be authenticated and would not leak the
client's system time information.

Note that this would be better than relying on HTTP timestamps because it
would work for any protocol, not just HTTP.