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

Eric Rescorla <ekr@rtfm.com> Sat, 12 March 2016 12:57 UTC

Return-Path: <ekr@rtfm.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 B1A3F12D636 for <tls@ietfa.amsl.com>; Sat, 12 Mar 2016 04:57:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 kjQ19YXJg5mi for <tls@ietfa.amsl.com>; Sat, 12 Mar 2016 04:57:09 -0800 (PST)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 5189012D631 for <tls@ietf.org>; Sat, 12 Mar 2016 04:57:09 -0800 (PST)
Received: by mail-yw0-x234.google.com with SMTP id g127so120195468ywf.2 for <tls@ietf.org>; Sat, 12 Mar 2016 04:57:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RCAhmqVnG//gXOUxSl7vbnBALPtT6p3sOmVFUJTpQWc=; b=s0YaLIm2ecISuUteC1ugt+MjQ19um9FSQlOkdHtDtY89mm4sfyOaO5BJYmvC8jeAPe 5aFD+r2Xji3FhCn5MU5xAXwU2V48PPcp6J2zcn2CdIzrTEAnz3aMet1r1FJcgmO1U7K5 Dy8f6GomfjsvUlrhBZPapI54ymAxg+/evQIxQS2qhf2wiQ7CdVi/0MEPp8M2epOO1L2o fFeTxrGNGAldhqfIVyDMF7noZbg2KowSz0GQAQ+WiofXZ7tr1Bo4gTeIPNu9nlSKw/Bi UQKkeuuxhPv1ZjJLvRdlQB/k0z6jQSoHgr/2JGbszNHb31ypDtKF/TA6V93CiHz74Ket bw0g==
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:from:date :message-id:subject:to:cc; bh=RCAhmqVnG//gXOUxSl7vbnBALPtT6p3sOmVFUJTpQWc=; b=JQv0E0vlfx/PnEtqk5R0e1BSbmyd7CxnpgH2a3mk7ydPbqlP2PUGwep6U9Wk4ddXSR idOfTN3i7nGO9+ORF/gTbkIxy29hTbn2qRKAQLOHrB8+a+EnOliOMH82wgm+0/VbTaWK x2pSNvZ8orO+O59aAjCcvzU6jDOGRF/RiR7/k8V9eF5V5upUrtdlAdQ/IETtC4VDPNT7 Iqdwmu/QpdlPZLRPe4wQRTM3TAJ48ICSviHFURacSHFsl+X9MyWewaWCcSByUNUGb/uF 4nxe/vOXY4a9dd+jZZNTYwSn9R+bkaWMRyYuAzkr8DLSlveRAbxRdG9WrNlQ9y/BpYNG 77BQ==
X-Gm-Message-State: AD7BkJItOrV5XpXovXo54Z6My/q8VqANuDnSLfxKDLt0NKy/DzulgtfatC79PEZcCNn+gRzLczBIoU+tdKQzYQ==
X-Received: by 10.13.218.198 with SMTP id c189mr8399226ywe.165.1457787428523; Sat, 12 Mar 2016 04:57:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Sat, 12 Mar 2016 04:56:29 -0800 (PST)
In-Reply-To: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com>
References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 12 Mar 2016 13:56:29 +0100
Message-ID: <CABcZeBPxMZEuG4KehxyhNafeQ4-HO9O-9ORn+BiQP0n3LJA_xw@mail.gmail.com>
To: Kyle Nekritz <knekritz@fb.com>
Content-Type: multipart/alternative; boundary=94eb2c08192ad60502052dd99532
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/tvx5ZbwZwJhJzT_SHqNvy5dMrhk>
Cc: "tls@ietf.org" <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: Sat, 12 Mar 2016 12:57:11 -0000

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