Re: [TLS] Simple, secure 0-RTT for the masses

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 16 March 2016 16:45 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 33F3312D54F for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 09:45:44 -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, 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 KJKsZnztB8WC for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 09:45:42 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0512D518 for <TLS@ietf.org>; Wed, 16 Mar 2016 09:45:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 3A1431E56; Wed, 16 Mar 2016 18:45:40 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id fHv4aDoN619j; Wed, 16 Mar 2016 18:45:40 +0200 (EET)
Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 011312310; Wed, 16 Mar 2016 18:45:40 +0200 (EET)
Date: Wed, 16 Mar 2016 18:45:39 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= <colm@allcosts.net>
Message-ID: <20160316164539.GB21439@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAH9QtQGdZ9=XG-Qc5G6amM1pOnBse5jZndL0kExxArWXoQbhsQ@mail.gmail.com> <CAAF6GDegiWr3cWPpQAiVTZ5RhWFg24C-=SB=b=tKVTpaPn3V5g@mail.gmail.com> <CAH9QtQHvrz0guqGeMxD-C1ifCLOvOuADGdeqtCMHkEnRZ=y+hw@mail.gmail.com> <CAAF6GDc+Lnzpx38YT0gvgetb8E9yVsgMkLMh1SB7tu=fw_SK4A@mail.gmail.com> <CAH9QtQF02zwnB6dOGjFfWX2RLc4_RSODFpHaVLZkK_5KDf93sg@mail.gmail.com> <CAAF6GDd0h=1--pViASw3pT5nMAM4SRy2C2hzA6XF7Ba_g+oL4w@mail.gmail.com> <20160316081717.GA21439@LK-Perkele-V2.elisa-laajakaista.fi> <CAAF6GDcAojmjOwuuwL-Vtk-U2VXa0JyXcqdZaDXrYmEuj=6eEA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAF6GDcAojmjOwuuwL-Vtk-U2VXa0JyXcqdZaDXrYmEuj=6eEA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WIqpj_9ELAY8rghE2DdSfiSOKBI>
Cc: "tls@ietf.org" <TLS@ietf.org>
Subject: Re: [TLS] Simple, secure 0-RTT for the masses
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: Wed, 16 Mar 2016 16:45:44 -0000

On Wed, Mar 16, 2016 at 08:12:48AM -0400, Colm MacCárthaigh wrote:
> On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara <ilariliusvaara@welho.com>;
> wrote:
> >
> > - Duplication of 0-RTT data into 1-RTT data of _different_ connection.
> >
> 
> I think using a different content type solves this; the early data is
> illegal in the 1-RTT phase and the content type would distinguish it.

Nope, this can not be realistically solved, _even_ with server state
(the 0-RTT to 0-RTT duplication is unsolveable without state, but can
be solved with server state).
 

> As an aside: an application protocol where latency is so sensitive that
> 0RTT is attractive would hardly have its own back-and-forth with banners in
> the first place.

The problem is that such banners would not be bound to the TLS connection
in any way, which causes problems (TLS has no facility to transport data
from application inside extension).


-Ilari