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

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.

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.

From [1]: > 0-RTT data can be replayed

If you want to allow 0-RTT, you need a way to specify which [api] calls are safe to run in 0-RTT, and which aren't. Which in turn requires a sort of scheduler for calls, making your network stack pretty complex.

In the post, for example, Facebook controls both the client and the server, so they can do that, but it's a non trivial problem for a general purpose library/implementation.

[1] https://code.facebook.com/posts/608854979307125/building-zer... (Section Time-bound 0-RTT data)

Even Facebook still requires the developers to manually declare things safe/unsafe for 0-RTT, and frankly the requirements for doing this securely are very subtle. This is a massive footgun.

You mean the most controversial.

Pirates are exciting. So are barbarian hordes, lions, blood-crazed sharks, and letters from the IRS.

Generally you don't want your software to be exciting. Not all of my peers agree

Replay attacks are a big issue with 0-RTT.

Until they get resolved it is best to not support it as TLSv1.3 loses some of its security guarantees.

Found a nice write-up of these issues here for anyone else interested:

https://github.com/tlswg/tls13-spec/issues/1001

TLS 1.3 0-RTT is not secure by default, but it is possible to provide both anti-replay and forward-secrecy properties for 0-RTT data with workarounds. As long as TLS 1.3 is not secure by default it is likely to lead to exploitable vulnerabilities that can only be fixed at the application level, distant from the cause. In general, it is also very challenging to fix applications to be idempotent and side-effect free.

Instead of shifting the problem to applications, we should strongly consider modifying the TLS 1.3 draft to make TLS 0-RTT secure by default, at least against replays. While Gillmor-style retry attacks will persist, these attacks may be mitigated with reasonable client behavior, and in many cases the existing client behavior is already fault tolerant.

0-RTT is sort of inherently vulnerable to replay at the protocol level. By definition you can't do any negotiation, so you can't get rid of replay attacks. 0-RTT is a special feature useful for specific applications where the security implications have been carefully thought through.

In other words, expect a large wave of 0-RTT vulnerabilities in the future.

Well, TLS 0-RTT is only for resumptions, not a client’s first connection to a server. And the writeup in the parent post suggests requiring the server to enforce atomic single-use resumption tickets, which would in fact get rid of replay attacks - at the cost of effectively prohibiting servers/CDNs from sharing tickets across multiple data centers, since then atomicity would require them to communicate (adding additional latency) before accepting each ticket.

Why would TLS add an insecure by default feature? Hasn't security been a problem for TLS historically?

Or is this aimed at higher end providers that can be trusted to only enable it for certain things? (Like, Google Search might benefit from it, and replays probably aren't an issue?)

Because Google said they'd abandon TLS and use QUIC-CRYPTO unless TLS had 0-RTT in the core standard. And that they insist on splicing the early data onto the TLS stream, smearing H2 traffic across both.

Maybe they're right and it'll all be fine—but I expect named bugs in the same family as Triple Handshake.

0-RTT is not automatically enabled. You need to opt in.

Like if you're a CloudFlare customer? https://blog.cloudflare.com/introducing-0-rtt/ They enable it for TLS 1.3 by default for "GET requests with no query parameters" and place at least some of the onus on the origin server to detect replays (via a "Cf-0rtt-Unique" HTTP header).

There was a talk at last year's Congress about the details of TLS 1.3 and many questions were asked at the end about 0-RTT. Was interesting to hear the cryptographer's, who work on the spec, opinions about that and things like why SNI is not encrypted by default.

Link: https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great...

and exciting :-)

And probably the one to be most badly implemented.