IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 09 May 2017 16:26 UTC

Return-Path: <ietf-dane@dukhovni.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 0B2A1129ADF for <tls@ietfa.amsl.com>; Tue, 9 May 2017 09:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 1SUMKy_Gy6Us for <tls@ietfa.amsl.com>; Tue, 9 May 2017 09:26:03 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D176B1294CC for <tls@ietf.org>; Tue, 9 May 2017 09:26:02 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id DE3D77A32F1 for <tls@ietf.org>; Tue, 9 May 2017 16:26:01 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>
Date: Tue, 09 May 2017 12:26:01 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <3510843A-8628-4859-B627-55C4EC7111D9@dukhovni.org>
References: <CAAF6GDfm=voTt_=JrdGtiaYby1JG8ySU2s6myjjpHKeGvi0bMg@mail.gmail.com> <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XLw7VysV6Kq1EVIxCEhTFhiqBV8>
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 16:26:04 -0000

> On May 9, 2017, at 12:00 PM, Salz, Rich <rsalz@akamai.com> wrote:
> 
> To me, the argument against this comes down to this:  The 0RTT data has
> different security properties than the post-handshake data, and TLS
> implementations should not hide that difference from applications.

What would a receiver API then look like?  Would it be something like:

  * Repeatedly request 0-RTT data until none-remains, if none expected
    or desired, fail if any found.

  * Then repeatedly request 1-RTT data via existing TLS APIs

  * Fail if 1-RTT data is requested and not all the 0-RTT data has yet
    been consumed?

Or did you have something else in mind?  What are your thoughts on the
sender side?  Just enable 0-RTT and have the toolkit send as much 0-RTT
data as "fits" and the rest 1-RTT, or an explicit request for a specific
0-RTT payload?

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email