IETF Logo Mail Archive

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

Jeffrey Walton <noloader@gmail.com> Sun, 13 March 2016 23:36 UTC

Return-Path: <noloader@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 BF10F12D775 for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 16:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 laHFs6SYFFXz for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 16:36:40 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 3B55912D6D4 for <tls@ietf.org>; Sun, 13 Mar 2016 16:36:40 -0700 (PDT)
Received: by mail-ig0-x22c.google.com with SMTP id nk17so27034488igb.1 for <tls@ietf.org>; Sun, 13 Mar 2016 16:36:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=kNYjzZxq+MJG63CtGEr+Q+apkBbyvlgo/IuKOc1b7Uk=; b=P9R4tFhET66ZVf8IZjmaO1QsGyfoEv4A0FQ60mSpjjztU0HNU4qWES3IKgxjGBWK7L 1kXrQXtjFEBRmgRUtrxKgsvinWMpwJMSp7Vt9447SJjt3mVElfGNrtjgtxRxWMIl3JeN WLArdUls96fT54GIN81ASOplyh/WL4jsmqOWSETQfvNbOghiX4n2X8V/s2hF7p8h4K9H 4GzuQrnVmuPFoZFt9a6SnOir+GlwhlF5CaGBPOvxBY10E5ziKiOqwfljh9kh5oVQcgel gvXjKV7gIJ0unwta7CzxaVcRsZGdCTmMM5mFuiRRaJnnvkeL18H9kx+32EY+wnIYdtuf 95OQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=kNYjzZxq+MJG63CtGEr+Q+apkBbyvlgo/IuKOc1b7Uk=; b=lkniNfE59iodLK63deKyTfQ9xOcCLwDEq82ZcYDoQ6nX3KLnPZCIvIKVapKt+fW8qX cO5RDCkFe3WeWVZVjqmitZYK3H1ANotJHgJTlzon7AKCRufE/J7Tk2vliSJBmV9SjFWc FK7XvqE1BSMpwd9xwugHCCtCxFqtqjrVE2kbewq7Fqs+ux3idQ4kGPdAd9eE3dcl/8Rk irW7xIkIGk5d6y/8fUq6zcK2a2CC9WwkB1ECtlhUePOyaJ59QyuwzKPm9+nzhYfDYLxH QVVCMcvYhMMx/POLOPL+qg1eBAG9VriO2WXz6qXtEM/NUyzlurclLAlFoNwTilD6ScNV dRfg==
X-Gm-Message-State: AD7BkJJwXhrBhDeFBCkSsOhtiob09VDUObelGacahKUA+XzX+k8om90rOhLhu/IIA2HaG3DWrHZ8LgdQN7E8FA==
MIME-Version: 1.0
X-Received: by 10.50.40.36 with SMTP id u4mr14068369igk.23.1457912199262; Sun, 13 Mar 2016 16:36:39 -0700 (PDT)
Received: by 10.36.195.133 with HTTP; Sun, 13 Mar 2016 16:36:39 -0700 (PDT)
In-Reply-To: <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com>
References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <CABcZeBPxMZEuG4KehxyhNafeQ4-HO9O-9ORn+BiQP0n3LJA_xw@mail.gmail.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com>
Date: Sun, 13 Mar 2016 19:36:39 -0400
Message-ID: <CAH8yC8nwyTf7N1y=NqmkVoY1tW6Kh4weFFLEFn6w3vLwoEMRSA@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/2ZzeurGnJ-fEqgu8zFzNB_eIMEs>
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
Reply-To: noloader@gmail.com
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 23:36:42 -0000

On Sat, Mar 12, 2016 at 12:45 PM, Karthikeyan Bhargavan
<karthik.bhargavan@gmail.com> wrote:
> 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

Be careful here. The whole point of 0-RTT is to start consuming data
before its authenticated to save a few milliseconds in network time.
All those parameters are controlled by the attacker.

We never worried about the extra roundtrip using satellite comms with
0.5 to 1.0 second delays. Additionally, most of my delays in fetching
web pages seems to be delays in Google APIs and servings third party
ads. 0-RTT seems to be a solution looking for a problem.

v2.23.0 | Report a Bug | By Email