IETF Logo Mail Archive

Re: [TLS] Closing on 0-RTT

Colm MacCárthaigh <colm@allcosts.net> Mon, 26 June 2017 17:25 UTC

Return-Path: <colm@allcosts.net>
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 A5299129C0E for <tls@ietfa.amsl.com>; Mon, 26 Jun 2017 10:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.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 vHOStsuA34l5 for <tls@ietfa.amsl.com>; Mon, 26 Jun 2017 10:25:49 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 5F85012EAF3 for <tls@ietf.org>; Mon, 26 Jun 2017 10:25:48 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id s9so2440502ybe.3 for <tls@ietf.org>; Mon, 26 Jun 2017 10:25:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OLdYXDMN6F9ebL0d/qoADHSciGAHtEkuXoN+J6F/Z9g=; b=1Qz2euGHTqoi4S2zapZS7yQ9Oikxj1+SHs46UIk3zHyV1vOAlTTl5O3ZwouuG4NEeg KAoo3YWOlrKjvzATOec3mElWe2HQghL+m8/t+4NtzjIzNO7VwXwfKZ8HXQtdOLSDeCQG wovWaMAqTAqNXiILAg4PHiWeyJ4X/ho+mNdVv8/awOF4WMTnjMaQm1GKWTf4/ANmCUTn wUzXQwEdo8NEYZ6zgOpO8m9vdMaD4LjHDf7SyZdGt1A4pSzDAd8X8r6JPmREW/BGYwXl aJLOXxv9K9ivTZKpLdDE8A6C0nTthq6YpKAl7OTzFwFzBJwp+0Nuh2y2VXMRLkxRwRUX 78vA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OLdYXDMN6F9ebL0d/qoADHSciGAHtEkuXoN+J6F/Z9g=; b=nvJY8204svggg6kdYvZa46TJsOih9JR8jzBSfUjLnLsH8gziMRXbgqfDZdr1asR+GV 4H2cydnDzUSaFWCHO5qDWFMeIzoL7hSGGIThPlasi5oW3boY7/8FtnuQIZXairjrn/Pk G1AV7VFJm1MUhA9Ex8qCYmL0N0yofs6ITtCNk/KL0rmeE9DFtVIsgtUt24yZJ2NtgkCG JrvcVQNmJlNMP+I2GKHGbXXxBffDWtfJ0Ib3fFJoKuX4SdhBdahM8WvRVwJDX8FEMMrk S/ufcJzjyPzdQ2Wwszm3XNGtrRnSfzreYcGp38FlVaFd38xcm4CfPNrFadkLluRLZteW AThg==
X-Gm-Message-State: AKS2vOxXOzA8rYa7Ynw+8aB9lUplJlIGhPbr5vjFXkkQFwRNlG34+5rD Tdwuu8jS+AzrVTNpdc638KG8uyna4Vp9
X-Received: by 10.37.22.213 with SMTP id 204mr925114ybw.204.1498497947459; Mon, 26 Jun 2017 10:25:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.93.197 with HTTP; Mon, 26 Jun 2017 10:25:46 -0700 (PDT)
In-Reply-To: <20170626064320.aguxkeikwdfhpnk5@LK-Perkele-VII>
References: <CABcZeBNLo51y4-MYS6NTQn9OWg5jTYYpwxn1fiKKNL5bWA37TA@mail.gmail.com> <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <CAH9QtQG0uk+eUozJxxMRwvcROO7x5FhKd5zDbwpCKuXj9zrecQ@mail.gmail.com> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <CAH9QtQFez=tUVJOd7ztBaWFtVs5dAAojg8JrixGqjwqN5go+8A@mail.gmail.com> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> <CAOgPGoAmo1p9BwfxyeA=iWbOpVtbxJsVpdN0TzVuV=bVyFiWEA@mail.gmail.com> <CABcZeBPw94Pn9J2LDLBSijs+aZhhOsTiGKHj0wgBq0Ev8kf=xA@mail.gmail.com> <20170624052727.26n4spscu77nlnlw@LK-Perkele-VII> <CABcZeBNSVu3BA=Zv8qH2QOzbu1xDcq_+3E6yBL==fg1uQ3K5vw@mail.gmail.com> <20170626064320.aguxkeikwdfhpnk5@LK-Perkele-VII>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Mon, 26 Jun 2017 10:25:46 -0700
Message-ID: <CAAF6GDeGZVft6ZHtTHYKOdzBeU_LJ8JN2qsT4uG1f0GHc09m6Q@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c13388db2f990552e03d99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/aXzebLYcu6E0sAV5QVsDkwjfiHU>
Subject: Re: [TLS] Closing on 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 26 Jun 2017 17:25:51 -0000

On Sun, Jun 25, 2017 at 11:43 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> I understood that the cache probing attack requires much less replays
> than the other side-channel ones. And furthermore, distributing the
> replays among zones makes the attack easier (because replay with the
> cached data hot doesn't tell that much).
>

In practice with real world HTTP caches, one replay is often sufficient.
That's because in addition to the faster load time you can look at the
cache headers (like max-age) to pinpoint that it was the replay that put
the item in the cache. This would work with DNS too, where TTL or RRSET
cycling leaks more information in the same way.

Using more zones does help, and if the attacker were targeting a busy
cache, then it can certainly help to weed out the noise and increase the
likelihood of finding a zone/node where the cache is empty to begin with.

-- 
Colm

v2.23.0 | Report a Bug | By Email