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

Karthikeyan Bhargavan <> Sat, 12 March 2016 17:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1102A12D62C for <>; Sat, 12 Mar 2016 09:46:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 hLVdCk9EEjnI for <>; Sat, 12 Mar 2016 09:46:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18F1912D62B for <>; Sat, 12 Mar 2016 09:46:09 -0800 (PST)
Received: by with SMTP id l68so54231104wml.1 for <>; Sat, 12 Mar 2016 09:46:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=s7GtUimwlnCygB0ZIHW28YJ+aoygo07/YlaPfSCLnvk=; b=QXb0pCJT97Plk6B5YuvMlmB/upU7GxXHGMw3BiF+3zrWtfL+tMHGyUG6mwRO266Cm9 P7apI+Bmx5fq0+VKfUrT1kYYeGfuRuRJva+20tKOevJ/C+uZd+Q6m4Q5X2uTUGlTMYs+ kyEy8fqjLKhFiw19bC7X64+KYmNanLID74DyyvfA9DyNvtrHQz84Wpo+2hUa2LZYRXIc /kAH+MIhr7QRXdKVT+uyCyavQQR1mutlrsvemjpXrWvGmob2rbQGPCoWrD4d6dt5ObyX ugQPlKKGl1WIt/nEbGWvV69IPr0xX8Vq4Tdz+T2b49l/Q/8Y5CBjrYDQDfuwPKz3WQsm dqqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=s7GtUimwlnCygB0ZIHW28YJ+aoygo07/YlaPfSCLnvk=; b=SyrN6+JsOlsExDEE/mFysxkNo5Si2/2GjZNox4N5iA4hjgya3cSg9U5KtWU8RPN/QS 52h0+p/B6vm/dBgRf29oVmLQlHhSI9TVds7b9BHPeVue4ykAt+IKIw7wx+GPlPC12HdH exETxWnjCfT8LQOsXCMRqYVAXyuXsLNU25KmiqmFJPOTcIPfaVlXrPDXIsxktq38qKeq XYrE0/Pm95+Kd+hsBDt1Mm5cSkX+vtHSnIK7CJCBGEEK5p+iXg7CJMaC7RgIdJfyKKRU BplUcTLpeb1re/3LALaFIsecEJPYQAKrMOIhw2KYqGqwBS+rL1Ddz73RGFiR3Sv7+buV ZGiw==
X-Gm-Message-State: AD7BkJLCtOEoUHKh8sXqc6T+A2EJ3NVsTL/uXVwSo0ZZ2Byh5aGpA3TN4svZz4Nne5qDcw==
X-Received: by with SMTP id j16mr9096069wmj.78.1457804767558; Sat, 12 Mar 2016 09:46:07 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id ka4sm14061864wjc.47.2016. (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2016 09:46:06 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3A8AAD93-D6BA-4138-AE06-1BFB09EE5886"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Karthikeyan Bhargavan <>
In-Reply-To: <>
Date: Sat, 12 Mar 2016 18:45:48 +0100
Message-Id: <>
References: <> <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.3112)
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 17:46:12 -0000

Hi Kyle,

In my talk at TRON, I was also concerned by potential attacks from allowing 
unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers should
implement replay protection using a cache, but requiring clients to provide
a timestamp in the client random is a great idea. Perhaps this would also
allow TLS 1.3 servers to detect clients whose clocks are too out-of-sync with
the server (and hence vulnerable to expired certificates)?


> On 12 Mar 2016, at 13:56, Eric Rescorla <> wrote:
> Hi Kyle,
> Clever attack. I don't think it would be unreasonable to put a low granularity time stamp in the
> ClientHello (and as you observe, if we just define it it can be done backward compatibly)
> or as you suggest, in an encrypted block. With that said, though couldn't you
> also just include the information in the HTTP header for HTTP? Do you think this is a sufficiently
> general issue that it merits a change to TLS.
> -Ekr
> On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz < <>> wrote:
> Similar to the earlier discussion on 0.5-RTT data, I’m concerned with the long term ability to replay captured 0-RTT early data, and the attack vectors that it opens up. For example, take a GET request for an image to a CDN. This is a request that seems completely idempotent, and that applications will surely want to send as 0-RTT data. However, this request can result in a few things happening:
>     1) Resource unavailable
>     2) Resource cached locally at edge cluster
>     3) Cache miss, resource must be fetched from origin data center
> #1 can easily be differentiated by the length of the 0.5-RTT response data, allowing an attacker to determine when a resource has been deleted/modified. #2 and #3 can also be easily differentiated by the timing of the response. This opens up the following attack: if an attacker knows a client has requested a resource X_i in the attacker-known set {X_1, X_2, ..., X_n}, an attacker can do the following:
>     1) wait for the CDN cache to be evicted
>     2) request {X_1, X_2, …, X_(n/2)} to warm the cache
>     3) replay the captured client early data (the request for X_i)
>     4) determine, based on the timing of the response, whether it resulted in a cache hit or miss
>     5) repeat with set {X_1, X_2, …, X_(n/2)} or {X_(n/2 + 1), X_(n/2 + 2), …, X_n} depending on the result
> This particular binary search example is a little contrived and requires that no-one else is requesting any resource in the set, however I think it is representative of a significant new attack vector that allowing long-term replay of captured early data will open up, even if 0-RTT is only used for seemingly simple requests without TLS client authentication. This is a much different threat than very short-term replay, which is already somewhat possible on any TLS protocol if clients retry failed requests.
> Given this, I think it is worth attempting to limit the time frame that captured early data is useful to an attacker. This obviously doesn’t prevent replay, but it can mitigate a lot of attacks that long-term replay would open up. This can be done by including a client time stamp along with early data, so that servers can choose to either ignore the early data, or to delay the 0.5-RTT response to 1.5-RTT if the time stamp is far off. This cuts down the time from days (until the server config/session ticket key is rotated) to minutes or seconds.
> Including the client time also makes a client random strike register possible without requiring an unreasonably large amount of server-side state.
> I am aware that client time had previously been removed from the client random, primarily due to fingerprinting concerns, however these concerns can be mitigated by
> 1) clients can choose to not include their time (or to include a random time), with only the risk of their .5-RTT data being delayed
> 2) placing the time stamp in an encrypted extension, so that it is not visible to eavesdroppers
> 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.
> _______________________________________________
> TLS mailing list
> <>
> <>
> _______________________________________________
> TLS mailing list