TLS 1.3 approved

Does someone know what the differences are between the final version and the draft that Chrome and Firefox enabled in Feb 2017? How much did they have to change for the middleboxes?

It does not. There are some passive decryption tools that will no longer work because they functioned by having non-forward-secure connections and the server's private key installed in the decrypter. (But one can just not support TLS 1.3 at the server to keep them working.)

MITM proxies, which are trusted by the client and which terminate and recreate the TLS connection, will continue to function. (Assuming they implemented TLS 1.2 correctly, which some didn't.)

Did banks and other network operators who require monitoring their traffic just deem the MITM proxies too expensive or complex, or what was the reason for their protest?

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 fronting

I 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

Which is why it should have never been implemented in TLS 1.3.

I believe the argument against not doing it was that some companies will just implement their own protocols instead. Eh, I think the chances of that happening were pretty slim. Now most of the problems we'll see with TLS 1.3 will likely be related to 0-RTT.

Also, wasn't that basically the same argument for implementing MITM in TLS 1.3? That if they don't do it the banks and middlebox guys will just stick to TLS 1.2 or whatever?

And who cares about a little bit of an extra HTTPS delay, when just adding Google analytics and Facebook Pixel to your site can increase the delay by over 400 ms? Some poor performance tracking tracking scripts add 800 ms on their own.