Re: [TLS] Simpler backward compatibility rules for 0-RTT
Hubert Kario <hkario@redhat.com> Tue, 28 June 2016 18:26 UTC
Return-Path: <hkario@redhat.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 8C6DC12D528 for <tls@ietfa.amsl.com>; Tue, 28 Jun 2016 11:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.348
X-Spam-Level:
X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-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 kk8ZECFcDt7U for <tls@ietfa.amsl.com>; Tue, 28 Jun 2016 11:26:34 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDDD12D1D7 for <tls@ietf.org>; Tue, 28 Jun 2016 11:26:33 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 762CA80B56; Tue, 28 Jun 2016 18:26:33 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-109.brq.redhat.com [10.34.0.109]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5SIQVaF018241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2016 14:26:33 -0400
From: Hubert Kario <hkario@redhat.com>
To: David Benjamin <davidben@chromium.org>
Date: Tue, 28 Jun 2016 20:26:25 +0200
Message-ID: <3937856.RExby9y8oT@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.4.13-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <CAF8qwaDy-rBRXRmFBYMPTGew1Q4g6Dwdgj8fong--jJvphZ78Q@mail.gmail.com>
References: <CABkgnnVgD2rTgdWkTEhd1b6CUpj_i7wD4-_E2Dd2=nJf1eW5RQ@mail.gmail.com> <2279135.STQlCAVDxp@pintsize.usersys.redhat.com> <CAF8qwaDy-rBRXRmFBYMPTGew1Q4g6Dwdgj8fong--jJvphZ78Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2318608.QtIYAy4oZL"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 28 Jun 2016 18:26:33 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vn6BFBaUPp2HXhIQ9TlnC4Gw46w>
Cc: 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: Tue, 28 Jun 2016 18:26:43 -0000
On Tuesday 28 June 2016 17:40:45 David Benjamin wrote: > On Tue, Jun 28, 2016 at 1:02 PM Hubert Kario <hkario@redhat.com> wrote: > > > On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote: > > > 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. > > > > here's a crazy idea: > > > > - introduce a new extension which has meaning of "more data follows" > > - if the server finds it, it expects another Handshake Protocol message > > from the client > > - the client sends a new "ClientHelloExtension" message that includes > > additional data, in practice it's continuation of the extension list > > (just let's use 3 byte length fields in the structure) > > > > the obvious downside is, that TLSv1.2 servers do not support it now > > > > the upsides are: > > * TLSv1.2 servers can be fairly easily updated to support > > it but ignore it (just feed the next message to handshake hash, but not > > interpret it) - that fixes the upgrade scenario and allows the process > > to > > be performed in two steps, either of which can then be safely reversed > > > > We could just as easily update TLS 1.2 servers to know how to skip early > data. Or, better yet, update those servers to TLS 1.3. you need to update the TLS1.2 server implementation only if you have a farm, are planning to use 0-rtt and only when you plan TLS 1.3 deployment soon > The problem is requiring those servers to update to begin with. At least > for browsers and the web, any solution that assumes we will get the entire > install-base updated in bounded time won't work. It took us 15 years to get > rid of SSL 3.0 and even then, with a widely publicized protocol bug and a > cutesy name, it was *still* a hassle and took a lot out of metaphorical > breakage budget. but we did, and the same thing will happen with TLS1.0, TLS1.1 and most likely TLS1.2 and at that time this mechanism will be usable for all servers as TLS1.3 servers will depend on it -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
- 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