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

Martin Thomson <> Sun, 13 March 2016 09:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7001412D560 for <>; Sun, 13 Mar 2016 01:36:29 -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 eYNFiYrR6l4t for <>; Sun, 13 Mar 2016 01:36:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C25E12D527 for <>; Sun, 13 Mar 2016 01:36:26 -0800 (PST)
Received: by with SMTP id nk17so19025598igb.1 for <>; Sun, 13 Mar 2016 01:36:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AtFKyo8OaD/H+zrU1Q63QeKvpPfFiTiOql8O2EOQx4M=; b=n9sLUdb48fZ79AcAA64QZFOamUpj/Mfa65L5hchG33cIgJlvdkeupJosPBj+ic+KEH 97jByBJu3roMlhSMr/zIQF0W7ntGWAhAMOGPEYGrxy6zTUlo66AgLZ57kbNUMhZt8WU2 UUo/oigMPOA/kS9IE1vJ/PpeG0tuwBVBKRWgHNyjIaSyhsCqZoFWvTVypzRlANndpuwn +XWqnR2V+8fZ1qQzQQ2gxpsydJDyK0sevQ6kMiZGU9A1MV9Qw2PaQyK7IO15wU+LUx4j lZCggqhmBV8iL/GYKQxKmw6EDWoX2LfKXr2Gyb29ZiosLgYc+2A7ZEyK83irho9U6fRf /nvA==
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=AtFKyo8OaD/H+zrU1Q63QeKvpPfFiTiOql8O2EOQx4M=; b=djf1KYUXAWrcvvQyCoAJKfAOqtzVbgyj7dp0ibX0fIrDEMOPkO6hyjzzVjLVzahTrx iw8u7jv5RuV85TMT+3tz/qxtqY8JRXYoxC9VlLqOhcNqHQQwu+psmVCfFpzrhd/qHOsW gu0DTbqIUOPXvH46Pt6ZSk2JHUnLE0twZ0htLMk4I7XkqwW2nWkLeCwFfE8pHjHUrYh7 v2E25ceD+vhiJResu4bLbHqw92IhU0esN8zsqWW8Ew5V6xM7r+AKKhAN9UtSTqS7CRLE yyFDWbrCfRUQVzpOyctZeM2oDNLeag/W7d8+JTNTwnoBbxHnBJZ2u1ikZnVNVSMDp7rw qLBw==
X-Gm-Message-State: AD7BkJITugLgV3nyFKWr+kI4U1hpIOhbl5uwxFONgGZLHIxizRO+aSZCdm+B/tvxPT61yzm76rETGpF55/J+WA==
MIME-Version: 1.0
X-Received: by with SMTP id e2mr12648455igr.77.1457861785809; Sun, 13 Mar 2016 01:36:25 -0800 (PST)
Received: by with HTTP; Sun, 13 Mar 2016 01:36:25 -0800 (PST)
Received: by with HTTP; Sun, 13 Mar 2016 01:36:25 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Sun, 13 Mar 2016 20:36:25 +1100
Message-ID: <>
From: Martin Thomson <>
To: Erik Nygren <>
Content-Type: multipart/alternative; boundary=047d7b10ce3bdffb5e052deae58c
Archived-At: <>
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: Sun, 13 Mar 2016 09:36:29 -0000

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.
>            Erik
> 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.
>> -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
> _______________________________________________
> TLS mailing list