IETF Logo Mail Archive

Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Geoffrey Keating <geoffk@geoffk.org> Mon, 14 March 2016 20:17 UTC

Return-Path: <geoffk@geoffk.org>
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 F00A612D5B5 for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 13:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 xoKloyhkKNah for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 13:17:08 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6AA112D54D for <tls@ietf.org>; Mon, 14 Mar 2016 13:17:08 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 240AF33D2A6; Mon, 14 Mar 2016 20:17:07 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Ryan Hamilton <rch@google.com>
References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> <CAAF6GDdc8JxH1Utms2ms6YFm7p+2SGqCChgfVd6-6m2So2_TSQ@mail.gmail.com> <m2egbcq3f0.fsf@localhost.localdomain> <CAJ_4DfQJGCptCP3T-JZma5JKoeHjgJqux6Z-qCLEeQN0tbd79w@mail.gmail.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Mon, 14 Mar 2016 13:17:07 -0700
In-Reply-To: <CAJ_4DfQJGCptCP3T-JZma5JKoeHjgJqux6Z-qCLEeQN0tbd79w@mail.gmail.com>
Message-ID: <m2a8m0q0fw.fsf@localhost.localdomain>
Lines: 22
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/njZiv7aFg4uK8A5aBZmZ-H0JPMA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe 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: Mon, 14 Mar 2016 20:17:11 -0000

Ryan Hamilton <rch@google.com> writes:

> On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <geoffk@geoffk.org>
> wrote:
> 
> > So, I don't think HTTP is generally safe against attacker-forced
> > replay, and would suggest great caution in allowing it.
> >
> 
> It's worth keeping in mind this recent paper about Replay attacks against
> HTTPS <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN>.
> TL;DR: Attackers can already force a browser to replay requests basically
> at will. ​As a result, it's not clear that 0-RTT replay makes this
> situation worse.

The blog indicates that it's possible to cause a browser to repeat a
request exactly once, within a short timeframe (probably 60 seconds or
so) before the browser times out; and the browser must not see the
first request succeed.  That's quite different from being able to let
a client make and complete a request, and then being to repeat that
request thousands of times over a period of hours or longer; even if
the client is a browser, it might be hard to convince it to do that.

v2.23.0 | Report a Bug | By Email