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

Hubert Kario <hkario@redhat.com> Mon, 21 March 2016 19:40 UTC

Return-Path: <hkario@redhat.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 02C3B12DAA2 for <tls@ietfa.amsl.com>; Mon, 21 Mar 2016 12:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level:
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 KDLYw5ZDcKst for <tls@ietfa.amsl.com>; Mon, 21 Mar 2016 12:40:19 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BC812D89D for <tls@ietf.org>; Mon, 21 Mar 2016 12:40:16 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id ED85164460; Mon, 21 Mar 2016 19:40:15 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-204-61.brq.redhat.com [10.40.204.61]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2LJeE1A009486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 15:40:15 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 21 Mar 2016 20:40:07 +0100
Message-ID: <5862743.k85ct04I0v@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <m2egbcq3f0.fsf@localhost.localdomain>
References: <56E54B85.4050204@cs.tcd.ie> <CAAF6GDdc8JxH1Utms2ms6YFm7p+2SGqCChgfVd6-6m2So2_TSQ@mail.gmail.com> <m2egbcq3f0.fsf@localhost.localdomain>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2342438.iOIDtIIVtI"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 21 Mar 2016 19:40:16 +0000 (UTC)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ymPlvqOmVH8seiqHSGEBgx6jxHY>
Cc: Geoffrey Keating <geoffk@geoffk.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, 21 Mar 2016 19:40:21 -0000

On Monday 14 March 2016 12:12:51 Geoffrey Keating wrote:
> 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.

Only in theory, in practice you can do most of the same things in GET's 
as you can in POSTs.

in other words, basically web frameworks can be made to modify server 
state upon receiving GET request

and even just the fact that the server thinks it has processed so many 
requests can be damaging (think timestamping service in which you pay 
per request)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic