TLS 1.3 approved
0-RTT sounds nice, until you get to appendix E.5. Everyone should read this:    E.5.  Replay Attacks on 0-RTT

    Replayable 0-RTT data presents a number of security threats to TLS-
    using applications, unless those applications are specifically
    engineered to be safe under replay (minimally, this means idempotent,
    but in many cases may also require other stronger conditions, such as
    constant-time response).  Potential attacks include:

    -  Duplication of actions which cause side effects (e.g., purchasing
       an item or transferring money) to be duplicated, thus harming the
       site or the user.

    -  Attackers can store and replay 0-RTT messages in order to re-order
       them with respect to other messages (e.g., moving a delete to
       after a create).

    -  Exploiting cache timing behavior to discover the content of 0-RTT
       messages by replaying a 0-RTT message to a different cache node
       and then using a separate connection to measure request latency,
       to see if the two requests address the same resource.

    Ultimately, servers have the responsibility to protect themselves
    against attacks employing 0-RTT data replication.  The mechanisms
    described in Section 8 are intended to prevent replay at the TLS
    layer but do not provide complete protection against receiving
    multiple copies of client data.  

It seems practically guaranteed a lot of devs will enable it without understanding the ramifications.. I hope embeddings like Nginx add a nice configuration interface like "enable_0rtt YES_I_UNDERSTAND_THIS_MIGHT_BE_INSANE;" or similar. Meanwhile I wonder if concentrators like Cloudflare will ever be able to support it, without knowing lots more about the apps they are frontingI guess e.g. Nginx could also insert an artificial header to mark requests received as 0-RTT, and frameworks like Django could use that header to require views be explicitly marked with a decorator to indicate support, or something like that