Re: [TLS] The case for a single stream of data

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 09 May 2017 18:12 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 5A661124D6C for <tls@ietfa.amsl.com>; Tue, 9 May 2017 11:12:32 -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 SPiVn3ue33FJ for <tls@ietfa.amsl.com>; Tue, 9 May 2017 11:12:30 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF05127B57 for <tls@ietf.org>; Tue, 9 May 2017 11:12:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 5D67821CE4; Tue, 9 May 2017 21:12:29 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id zzuWRHkeLW3o; Tue, 9 May 2017 21:12:29 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id F21E0C4; Tue, 9 May 2017 21:12:28 +0300 (EEST)
Date: Tue, 09 May 2017 21:12:27 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Colm MacCárthaigh <colm@allcosts.net>
Cc: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170509181227.GA9346@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAAF6GDfm=voTt_=JrdGtiaYby1JG8ySU2s6myjjpHKeGvi0bMg@mail.gmail.com> <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDcGQ0YTYFFD+HVD71O9GCW7V3r_UNce1LQsHF1Zs9aBLQ@mail.gmail.com> <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDd5jnuSHw3JLTuCCKWjwKHcW=nfNac=w5UprM-gPJocQw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAF6GDd5jnuSHw3JLTuCCKWjwKHcW=nfNac=w5UprM-gPJocQw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SySG9SIZh_HJgiCkQl9AEHx4PWQ>
Subject: Re: [TLS] The case for a single stream of data
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: Tue, 09 May 2017 18:12:32 -0000

On Tue, May 09, 2017 at 10:35:37AM -0700, Colm MacCárthaigh wrote:
> On Tue, May 9, 2017 at 9:41 AM, Salz, Rich <rsalz@akamai.com> wrote:

> >The second problem is that middle-boxes can break any signaling. For
> > example a CDN or TLS accelerator may enable 0-RTT towards the back-end
> > origin without enabling it to the original client. In this model, the
> > client has *no* way to reason about retries or replay.
> >
> > A CDN is not a middlebox.  As far as the client is concerned a CDN *is*
> > the origin.
> 
> 
> No I don't think this works in transactional systems. For example; suppose
> the client performs an update or write "through" the CDN, and 0-RTT is
> being used on both sides. In the 0-RTT world, the CDN might be subject to
> replay between the CDN and the Origin. But as defined, the actual client
> gets no visibility of that. That breaks careful clients.  For example they
> may get a 500 back and assume that the request failed, without knowing that
> the request may be replayed any time in the next 10 seconds and therefore
> succeed.

Doesn't this imply that clients or CDN are using unsafe HTTP methods in
0-RTT data? Which is of course _seriously_ broken.

Because HTTP specification expressly forbids any and all updates and
writes using safe methods. Ignoring that causes very severe security
vulernabilities even today (e.g., causes essentially undefendable CSRF
attacks).



-Ilari