
TLS 1.3 at Apple - okket
https://mailarchive.ietf.org/arch/msg/tls/38hn9mRARfDpNdwVKXSpCFhRXs4
======
netheril96
> Note, we currently do not have 0-RTT data support.

That is like the most exiting feature of TLS 1.3.

~~~
daenney
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
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
> 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.

