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

Martin Thomson <martin.thomson@gmail.com> Sun, 13 March 2016 09:36 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7001412D560 for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 01:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYNFiYrR6l4t for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 01:36:26 -0800 (PST)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C25E12D527 for <tls@ietf.org>; Sun, 13 Mar 2016 01:36:26 -0800 (PST)
Received: by mail-ig0-x232.google.com with SMTP id nk17so19025598igb.1 for <tls@ietf.org>; Sun, 13 Mar 2016 01:36:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.50.60.34 with SMTP id e2mr12648455igr.77.1457861785809; Sun, 13 Mar 2016 01:36:25 -0800 (PST)
Received: by 10.36.43.5 with HTTP; Sun, 13 Mar 2016 01:36:25 -0800 (PST)
Received: by 10.36.43.5 with HTTP; Sun, 13 Mar 2016 01:36:25 -0800 (PST)
In-Reply-To: <CAKC-DJjVECKakNyQ+RHKkGfp6WOT+Z4=bvDf27ZT4zRFDUdtuw@mail.gmail.com>
References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <CABcZeBPxMZEuG4KehxyhNafeQ4-HO9O-9ORn+BiQP0n3LJA_xw@mail.gmail.com> <CAKC-DJjVECKakNyQ+RHKkGfp6WOT+Z4=bvDf27ZT4zRFDUdtuw@mail.gmail.com>
Date: Sun, 13 Mar 2016 20:36:25 +1100
Message-ID: <CABkgnnVp=zavzETMXmUSHQ8NzhSxyS=BqEehKC9JJKi6_qos5g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Content-Type: multipart/alternative; boundary=047d7b10ce3bdffb5e052deae58c
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/b-E5FrLD7yEOlWl-4_c62p09Do0>
Cc: tls@ietf.org
Subject: Re: [TLS] Limiting replay time frame of 0-RTT data
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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" <erik+ietf@nygren.org> 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 <ekr@rtfm.com> 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 <knekritz@fb.com> 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>