Re: [TLS] Simpler backward compatibility rules for 0-RTT
Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 23 June 2016 15:53 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 2FBB112B028 for <tls@ietfa.amsl.com>; Thu, 23 Jun 2016 08:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 vT-lQErNMOwv for <tls@ietfa.amsl.com>; Thu, 23 Jun 2016 08:53:42 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3B63012B034 for <tls@ietf.org>; Thu, 23 Jun 2016 08:53:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 9E3607DD5; Thu, 23 Jun 2016 18:53:40 +0300 (EEST)
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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id RjAsuqtDZM-A; Thu, 23 Jun 2016 18:53:40 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 515C92317; Thu, 23 Jun 2016 18:53:40 +0300 (EEST)
Date: Thu, 23 Jun 2016 18:53:39 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20160623155339.GA5659@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABkgnnVgD2rTgdWkTEhd1b6CUpj_i7wD4-_E2Dd2=nJf1eW5RQ@mail.gmail.com> <CAJ_4DfQ1ttyF0z9vwmuq-yEvbHrh+93k3rkJ7gzgDQZoQnuUpQ@mail.gmail.com> <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaCQSERcYNr42=DB-ZcBQde5qkrk8R_AD2qnnEsdwi7NoA@mail.gmail.com> <CABkgnnUsnz3Uh8dH=ke9uO82cgP3S7nJ0fgcs=JpsZu3qr0K0g@mail.gmail.com> <CACsn0c=EcXyrB83HnSbWWrQG5T2AjDQdG2D408qiDjqXEY3Htg@mail.gmail.com> <CABkgnnXdFJHEA60x-KObf_dT1aS5ys49mO4Uffmmw4sKwNX8Yg@mail.gmail.com> <CACsn0cn=B36Tn0O=RaUebAtjqxRVcQFD+kWyFVfXELiHY2ux2w@mail.gmail.com> <CABkgnnV4+_TvAGQ2SYWi+REnxSLgV+D_H3gKw0Rz6fswqd8iiA@mail.gmail.com> <CACsn0cmaEcKJsPg418oEoq_QX=+AS-JXzTgp5E=QF7yk_Nqq5w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CACsn0cmaEcKJsPg418oEoq_QX=+AS-JXzTgp5E=QF7yk_Nqq5w@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/a4hkj4tQ6u8ers0Br0BuDpwn39c>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT
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: Thu, 23 Jun 2016 15:53:45 -0000
On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote: > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson > <martin.thomson@gmail.com> wrote: > > On 22 June 2016 at 12:01, Watson Ladd <watsonbladd@gmail.com> wrote: > >> Why isn't 0-RTT an extension in the Client Hello to deal with this? > > > > You can't stream extensions, which unfortunately is required given how > > most software interacts with their TLS stack. > > A few months ago we had a lengthy discussion on the list and at TRON > about how risky 0-RTT is. This culminated in the idea that 0RTT data > should be provided through a distinct channel to the application, > along with feedback about whether it was not accepted. If we're > willing to change the interaction pattern to support that, we can > accommodate using 0RTT as an extension by gathering it all and sending > when the handshake happens. But it sounds like you are discussing a > design where the handshake fakes completion if 0-RTT is on, and at > some point later "well, i didn't actually send the data you wanted > to". Or am I missing something about the API design that is motivating > this streaming approach? Sticking 0-RTT data into ClientHello also has the following problems: - One needs to mangle ClientHello (strip an extension on receiver side) to obtain hash suitable for key derivation for 0-RTT. To do it any other way either doesn't work, or are cryptographically quite risky. - It bloats ClientHello, something you rather not bloat, especially with DTLS. And one still has to keep the data separate. For one, one can't guarantee non-replay (no, the ticket age won't cut it, for both fundamental and practical reasons). The streaming appoach on client end could take forms of either pre-collecting the data, or callback after ClientHello (and the assorted hashes being known, altough the latter is somewhat more dangerous...) And BTW, that 0-RTT Finished message is quite annoying... -Ilari
- Re: [TLS] Simpler backward compatibility rules fo… Ilari Liusvaara
- Re: [TLS] Simpler backward compatibility rules fo… Hubert Kario
- Re: [TLS] Simpler backward compatibility rules fo… Hubert Kario
- Re: [TLS] Simpler backward compatibility rules fo… Erik Nygren
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… Ilari Liusvaara
- Re: [TLS] Simpler backward compatibility rules fo… Watson Ladd
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… David Benjamin
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… Watson Ladd
- Re: [TLS] Simpler backward compatibility rules fo… Bill Frantz
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… David Benjamin
- Re: [TLS] Simpler backward compatibility rules fo… Ilari Liusvaara
- Re: [TLS] Simpler backward compatibility rules fo… Ryan Hamilton
- [TLS] Simpler backward compatibility rules for 0-… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… Watson Ladd
- Re: [TLS] Simpler backward compatibility rules fo… David Benjamin