Good riddance to the log spam this misfeature creates.
Can't understand why anyone would want to use this approach with TLSv1.3 unless you're only ever going to have one server instance per region and want to use 0-RTT with OpenSSL's anti-replay feature.
Conversation
I wrote a nice explanation in the commit message for why this feature doesn't make any sense. Only reason we left it enabled was in case the bots that are still using TLSv1.2 supported session ids but not session tickets. Would have been a no-op once we disable TLSv1.2 anyway.
1
2
1
There are still some important services without TLSv1.3 for their crawlers. For example, Google can't fetch MTA-STS configurations via TLSv1.3. Not particularly surprising since the people who designed / implemented that feature at Google don't understand or care about security.
1
2
1
After looking into it to see if it made sense to enable for completely static web services, TLSv1.3 0-RTT is horrifying and shouldn't be used anywhere. It should be removed from TLSv1.4. It's a bad enough misfeature that TLSv1.3 is a rotten standard as a whole and failed users.
1
3
5
TLSv1.3 improves forward secrecy for normal session resumption if you stick to the modern approach, which is the case for the web at least. On the other hand, it destroys that and other security properties with 0-RTT and 0-RTT has huge adoption (Cloudflare, Google, etc.) already.