Re: [TLS] The case for a single stream of data

[Ilari Liusvaara <[e-mail]>]

On Thu, May 11, 2017 at 12:00:17AM -0500, Benjamin Kaduk wrote:
> 
> First off, it seems somewhat self-evident that if we guarantee 0-RTT
> non-replay, then of course it makes sense to just concatenate the
> streams.  That is, if 0-RTT data is not replayable, there's not much
> special about it to merit separating it off from normal application
> data.  This isn't quite exactly true because of the DKG attack, but it
> may be close enough to not matter.
> 
> However, I'm still not convinced that requiring strong 0-RTT non-replay
> is feasible/the right thing to do.  So, I do not consider the question
> of single stream vs. block-of-early-data + 1-RTT stream to be settled.

There are deeper problems than that:

- Strict HTTP clients can't allow autoreplay if 0-RTT contains a POST
  (and any HTTP client that isn't strict is a lost cause anyway).
- Ensuring that there is no race causing possible data corruption if
  the server rejects 0-RTT.
- Concatenation seems to play poorly with 0-RTT exporters (which start
  to seem like an attractive nuisance...).


Also, turns out that unordered replay is just fundamential. So any
_existing_ systems that don't handle unordered replay can be broken,
and there isn't anything TLS can do about that.

Which leaves the "loads of replays" problem from lack of strong 0-RTT
replay protection.



-Ilari