
Introducing TLS 1.3 - samber
https://blog.cloudflare.com/introducing-tls-1-3/
======
colmmacc
TLS 1.3 is still an evolving draft, and who knows what may change before it is
standardized, but so far it does have some long-overdue simplifications to
TLS. My favorite is that session resumption has been merged with pre-shared-
key (PSK) mode, since really they are the same thing; that's a genius idea
that is a good example of reducing the surface area for mistakes or attacks.

But (of course there was a but coming) ... the new 0-RTT mode seems like a bad
idea, and I think it will come to be a really weak spot, and where many
practical attacks will show up; which is unfortunate.

Quick primer: 0-RTT data is where the client can send data to the sever from
the get-go, as long as the client and server have communicated before. The
data is sent by the client effectively /while/ the handshake is happening. The
server might discard that data, because it might not have the decryption key
used any more, and the client would have to resend it in this case. But the
real idea is that the client can send the requests it wants and the server can
get a head-start on building the responses while the handshake is happening.
It speeds things up. For most cases this mode will actually be "1 RTT",
because a TCP connection still needs to be established and that costs 1-RTT
without fast-open, but TLS won't be adding a round trip.

One problem is that a mixed mode handshake where data can come in while the
handshake is happening complicates already brittle state machines in the TLS
libraries, and I bet we'll see vulnerabilities there similar to the
change_cipher_spec vulns that hit some TLS implementations, but the real issue
is more fundamental and is mentioned in the draft itself ...

    
    
        IMPORTANT NOTE: The security properties for 0-RTT data (regardless of
        the cipher suite) are weaker than those for other kinds of TLS data.
        Specifically.
    

The short of it is that the 0-RTT data doesn't get Forward Secrecy, and it
isn't protected against replay. Losing forward secrecy seems like a big loss,
because 0-RTT is where passwords, authentication tokens, and credit card
numbers are likely to be; many real-world requests need these things and
developers will put them there. So the most sensitive data ends up with the
weakest secrecy.

But replay-ability is a bigger concern. Making a request pattern truly
idempotent is very very hard; even the smartest developers often mess it up.
So if an attacker, and I mean someone using the same wifi hotspot, can grab
your request data and replay it who knows what's happening; simple attacks are
things like exhausting your server-side throttle limits and creating a DoS
that locks the client out, or causing you to be charged multiple times if the
request is something you pay for.

Slightly more complicated attacks may be observing side-effects of what
happens when a request is replayed to derive information about that request.
For example if the server primes a cache based your request, I could replay it
and probe what items have now been cached. Now I can determine what your
request was for.

Servers can put mitigations in place; like they can keep a log of all 0-RTT
data and make sure it's never duplicated, but to do this robustly requires
transactions (distributed ones if it's a distributed system, like a CDN) and
it's the kind of thing many will punt on. There are other ideas like time-
windowing, similar to the kind of windowing DTLS permits, but those too have a
history of error and vulnerability, and may not be practical.

All while leaving 0-RTT there as a very tempting way to save some speed.

