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