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

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.

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.

David

>  * makes it possible in the future, if we are forced to, support post
> quantum
>    crypto that requires key shares that won't fit in current extensions
> field
>
> --
> 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_______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>