Re: [TLS] Closing on 0-RTT

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 24 June 2017 05:27 UTC

Return-Path: <ilariliusvaara@welho.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 06E49129B9D for <tls@ietfa.amsl.com>; Fri, 23 Jun 2017 22:27:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 INxTYJYVVpiM for <tls@ietfa.amsl.com>; Fri, 23 Jun 2017 22:27:34 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 541D7129B79 for <tls@ietf.org>; Fri, 23 Jun 2017 22:27:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id A297C23876; Sat, 24 Jun 2017 08:27:31 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id i96SD2gR1dnU; Sat, 24 Jun 2017 08:27:31 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 23B9827B; Sat, 24 Jun 2017 08:27:28 +0300 (EEST)
Date: Sat, 24 Jun 2017 08:27:27 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Joseph Salowey <joe@salowey.net>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170624052727.26n4spscu77nlnlw@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBPw94Pn9J2LDLBSijs+aZhhOsTiGKHj0wgBq0Ev8kf=xA@mail.gmail.com>
User-Agent: NeoMutt/20170306 (1.8.0)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PRAzLK6m2iAc0yZ3jn9YE5M_rz4>
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: Sat, 24 Jun 2017 05:27:37 -0000

On Fri, Jun 23, 2017 at 10:44:00AM -0700, Eric Rescorla wrote:
> 
> On Fri, Jun 23, 2017 at 9:21 AM, Joseph Salowey <joe@salowey.net> wrote:
> 
> > Discussion on this topic is dying down, can you post a PR so we can see
> > the proposed text.  There is still some discussion on the API thread so
> > there may be some additional modifications coming in that area.
> >
> PR up:
> https://github.com/tlswg/tls13-spec/pull/1034

I didn't see any mention of the cache probing attack.

I.e., Leak data from 0-RTT requests (especially URLs) by first priming
caches using 0-RTT replay and then probe the caches using normal
requests.

This attack can be viable even at low replay count, it isn't like the
others that require very high number of replays. And in fact, it
benefits from having numerious zones.


E.g., CDNs that have multiple datacenters that accept 0-RTT tickets of
each other seem vulernable to abusing this for discovering HTTP GET
URLs in 0-RTT requests.


-Ilari