0-RTT sounds nice, until you get to appendix E.5. Everyone should read this:<p><pre><code> 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.
</code></pre>
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<p>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
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?
No banking backdoor either, Sanity won out!<p>See below if you haven't come across this
<a href="https://www.thesslstore.com/blog/tls-1-3-banking-industry-working-undermine-encryption/" rel="nofollow">https://www.thesslstore.com/blog/tls-1-3-banking-industry-wo...</a>
<a href="https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00" rel="nofollow">https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-...</a>
If I'm not mistaken this means no "authorized" MITM<p><pre><code> - Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.</code></pre>
So it looks like that this seasons NSA/GHCQ backdoor is 0-RTT, and will be implemented into the commercial variants, whilst the open source variants will turn it off by default.
Or use it like Cloudflare, in HTTPS without GET params only.