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

Kyle Nekritz <> Mon, 14 March 2016 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A3EC12D732 for <>; Mon, 14 Mar 2016 13:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WzWGccHqD4a7 for <>; Mon, 14 Mar 2016 13:43:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 97B6512D6D2 for <>; Mon, 14 Mar 2016 13:43:14 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u2EKfBdg015834; Mon, 14 Mar 2016 13:43:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=p2TJ9K6r+FLRNWiLY/NsPP9SOysaNeK07bBkAFNg73s=; b=nAEXsgcwULx5us4v+QUwwVlHs7Rx8vRVidZ6PLgAJuBCMh2C03TJSEh73fdPFiZxsXLl zlU9nTyzTyJU1KXstEaQgKoMgMAdSxHe6S1Iri/2hFdu9l6+aPtw2Ccyq52md0ekJ5ne CntDjd47Ms4eRYGX9rJJSMmz4GBzTxBV7m8=
Received: from ([]) by with ESMTP id 21p2m810hh-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Mar 2016 13:43:13 -0700
Received: from ([]) by ([fe80::c983:d64f:e422:461d%12]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 13:43:12 -0700
From: Kyle Nekritz <>
To: Martin Thomson <>, Erik Nygren <>
Thread-Topic: [TLS] Limiting replay time frame of 0-RTT data
Thread-Index: AdF70pHzy4ySAXIcRV+Hke2bem/g9AAzxQ6AAB0ZPQAADBwwgAAu96JQ
Date: Mon, 14 Mar 2016 20:43:11 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8A79BFEDF6986C46996566F91BB63C860D6536DAPRNMBX021TheFac_"
MIME-Version: 1.0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-14_06:, , signatures=0
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: Mon, 14 Mar 2016 20:43:17 -0000

As others have said I do think adding client time solves much more than just this specific issue. Running a client nonce cache at scale also likely requires client time in order to limit the storage needed to a reasonable amount.

I like the idea of including time since receiving the session ticket instead of absolute time. This allows for clients with high clock skew but still an accurate steady clock to use 0-RTT, and likely for tighter bounds to be placed on the time.  The natural place to put this would be the client hello, where it would be unencrypted, which would leak the time of ticket issuance. How concerning is this, is it worth encrypting this time?


From: TLS [] On Behalf Of Martin Thomson
Sent: Sunday, March 13, 2016 5:36 AM
To: Erik Nygren <>
Subject: Re: [TLS] Limiting replay time frame of 0-RTT data

I assume that you would run a tight tolerance on the 0RTT resumption by saving the client's clock error in the ticket.  That a way only clients with bad drift get no 0RTT. To do that all sessions need time.

I do not see how the server can do this in general without client help. But the solution also addresses Brian's concern. The client doesn't need absolute time, just relative time: How long since the ticket was issued. Then it's an addition to the psk_identity only.
On 13 Mar 2016 1:49 PM, "Erik Nygren" <<>> wrote:
That does seem like a good idea to include a client time stamp in the 0RTT flow to let the server force 1RTT in the case where this is too far off as this bounds the duration of the replay window.  (I suspect we'll find a whole range of other similar attacks using 0RTT.)  An encrypted client timestamp could presumably be probed by the server.  (ie, if the server response is a different size for timestamp-expired vs timestamp-not-expired an attacker could keep probing until they change?)  That does seem like more effort, however.

On Sat, Mar 12, 2016 at 7:56 AM, 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.


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<><>

TLS mailing list<><>