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

[Ilari Liusvaara <[e-mail]>]

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.

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