3 ms·

It's also a contested one as it can open one up to issues. Some of these are detailed here, for example: https://github.com/tlswg/tls13-spec/issues/1001 https:/

It's also a contested one as it can open one up to issues. Some of these are detailed here, for example: https://github.com/tlswg/tls13-spec/issues/1001 https://github.com/tlswg/tls13-spec/issues/1001 It seems prudent to not support something like 0-RTT until the consequences of it are well understood and an informed decision can be made on if the increased speed is worth its trade-offs and how best to protect the data in transit from its potential issues.

derefr 9y ago
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?
- daenney 9y ago
  > 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.
- brians 9y ago
  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.
- throwaway2048 9y ago
  Some people will rush headlong into the new and shiny features, they always do. Let them take the lumps.

derefr 9y ago

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?

daenney 9y ago
> 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.
brians 9y ago
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.
throwaway2048 9y ago
Some people will rush headlong into the new and shiny features, they always do. Let them take the lumps.