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

Geoffrey Keating <geoffk@geoffk.org> Mon, 14 March 2016 19:12 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 67DF512D6D5 for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 12:12:55 -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 hT4H87N8GLr9 for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 12:12:54 -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 190A612D50C for <tls@ietf.org>; Mon, 14 Mar 2016 12:12:54 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 2267533D252; Mon, 14 Mar 2016 19:12:52 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: =?utf-8?b?Q29sbSBNYWNDw6FydGhhaQ==?= =?utf-8?b?Z2g=?= <colm@allcosts.net>
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>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 14 Mar 2016 12:12:51 -0700
In-Reply-To: <CAAF6GDdc8JxH1Utms2ms6YFm7p+2SGqCChgfVd6-6m2So2_TSQ@mail.gmail.com>
Message-ID: <m2egbcq3f0.fsf@localhost.localdomain>
Lines: 40
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/OI6XWaB3rrys4c-2SYvDUplivaI>
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 19:12:55 -0000

Colm MacCárthaigh <colm@allcosts.net>; writes:

> On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar <subodh@fb.com>; wrote:
> >
> > Like Kyle mentioned the thing that 0-RTT adds to this is infinite
> > replayability. As mentioned in the other thread we have ways to reduce the
> > impact of infinite replayable data for TLS, making it reasonably replay
> > safe.
> >
> 
> That too is a mis-understanding. The deeper problem is that a third party
> can do the replay, and that forward secrecy is gone for what likely is
> sensitive data. Neither is the case with ordinary retries.

Just to expand on this:

HTTP GET is idempotent and so replayable, correct?  That is, if you
send two GET requests in a row, you should get the same results, no
changes should be caused on the server side, and the attacker learns
nothing new, even if the attacker could not have issued the original
GET.

However, just because this is true for two sequential GET requests, it
may not be the case for a series of requests.  For example, a GET
followed by a PUT followed by another GET.  If the second GET is
performed by an attacker, it might reveal that the PUT has occurred
and the new size of the result.

Further issues can occur depending on the application.  For example,
if the result contains a timestamp, some sensitive numeric data, and
is compressed, then repeated queries will leak information about the
numeric data at a higher rate than if the attacker had to rely on
passive monitoring.

So, I don't think HTTP is generally safe against attacker-forced
replay, and would suggest great caution in allowing it.  Perhaps we
could say, in the TLS RFC or a new RFC covering the topic, that it
should only be allowed by servers and clients when serving/requesting
immutable static data, that is for requests that will only ever return
one result.