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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
