How is anyone going to understand the consequences unless someone actually implements it in a stack (behind a feature-flag) that people are then encouraged to go play with—exactly as is being done here with TLS 1.3 itself?

In other words: wouldn't 0-RTT be the thing it'd be most interesting to see a limited-opt-in real-world test of? Why bother testing TLS 1.3 without it?

> How is anyone going to understand the consequences unless someone actually implements it in a stack (behind a feature-flag) that people are then encouraged to go play with—exactly as is being done here with TLS 1.3 itself?

If you read the issue that I linked, it's already been tested and a number of flaws found. It has also been tested by others who've also verified the issue with potential replay attacks. Putting something that is known to already have flaws behind a feature flag so others can, potentially unknowingly, start using it doesn't seem like a useful exercise to me and does little to gain additional data on the matter. Once the existing issues are resolved it might be more interesting to try what you're suggesting.

Oh, it's badly flawed enough that it's visible without testing. The way some TLS libraries are implementing it---fusing the early data with the regular stream---is a recipe for Triple Handshake style bugs.

What's going to be interesting about broad rollout of 1.3 without 0RTT is the effect of middle boxes and other crud trying to parse streams as they forward.

Some people will rush headlong into the new and shiny features, they always do. Let them take the lumps.