Re: [TLS] Simpler backward compatibility rules for 0-RTT

[Hubert Kario <[e-mail]>]

On Tuesday 28 June 2016 17:40:45 David Benjamin wrote:
> On Tue, Jun 28, 2016 at 1:02 PM Hubert Kario <[e-mail]> 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
> > > > <[e-mail]> wrote:
> > > > > On 22 June 2016 at 12:01, Watson Ladd <[e-mail]> 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