A Readable Specification of TLS 1.3

> I wonder what the motivation behind that was

Middleboxes.

While the Internet is supposed to be end-to-end, there's no shortage of intermediate systems that pretend to understand the upper-layer protocols being carried, and that act on that what they think they see. Every single change to the visible parts of a protocol, no matter how small, risks breaking when one of these observers are present. TLS has been hit particularly hard by that; TLS 1.3 was delayed for many months while the protocol designers tried to figure out how to change the protocol without it being rejected by these interlopers. In the end, the solution was to make all TLS 1.3 connections pretend to be TLS 1.2 session resumption connections, and hide the real protocol negotiation within the encrypted session.

> setting up what is effectively an anonymous (EC)DH session first seems to provide no extra protection from an active MITM because it's unauthenticated

It's actually authenticated with the server certificate (and client certificate if one is being used); the authentication covers the whole protocol negotiation.

Since with active MITM the intermediate box has to be one of the ends of each half of the connection (otherwise the authentication will fail since the ECDH keys won't match), the protocol negotiation protects against misunderstandings: if the MITM box does not understand TLS 1.3 (or any future version), it will negotiate TLS 1.2, instead of getting confused by all the changes to the protocol in TLS 1.3.

> as far back as SSL 2.0, and presumably 1.0, there seemed to be no attempt to make the whole protocol encrypted

The goal back then was to protect the data, not the metadata. Only recently have the bad experiences with protocol ossification caused by broken middleboxes led protocol designers to also protect as much as possible of the metadata.

You can imagine it, but the person you’re replying to is closer. 1.3 is a ground-up redesign, packaged to not bother middleboxes that look for TLS 1.2.

The handshake process and difference is complete.

> I wonder what the motivation behind that was --- I'm no cryptographer, but setting up what is effectively an anonymous (EC)DH session first seems to provide no extra protection from an active MITM because it's unauthenticated.

So first let's explicitly point out that it stops passive snooping.

Even in the presence of MitM, it provides protection. An attacker can get access to a specific handshake, but the client will know and can kill the connection and alert the user. It can't be done behind the scenes on every connection.

> I'm no cryptographer, but setting up what is effectively an anonymous (EC)DH session first seems to provide no extra protection from an active MITM because it's unauthenticated

It makes the protocol easier to reason about coherently, which in TLS 1.3 was a priority for the first time. The cryptographers reasoned about an abstract protocol and produced various types of proof about the properties this protocol has, and then the engineers in the TLS WG figured out which bits to send on the wire to communicate that protocol in a way that doesn't blow up too many middleboxes.

We can consider two separate possibilities:

1. The usual case, the two parties were actually Alice and Bob. Bob (and optionally Alice) now bind proof of identity to the secure channel using CertificateVerify messages, which is possible because they are, in fact, Alice and Bob, and we have an authenticated secure channel between Alice and Bob.

2. The MITM case. Alice is talking to Mallory. Mallory may also be talking to Bob. Mallory cannot show Bob's binding to the Mallory-Bob channel to Alice as proof she is Bob. It's bound to the wrong channel. She can't make her own proof, that's the whole point of the public key cryptography used for the proofs. So Mallory can't prove to Alice that she is Bob, and so Alice won't send her any messages for Bob.

But also yes a subsidiary rationale is the one a sister message explains, that encrypting things stops a middlebox from tampering with them. Consistently over its lifetime _everything_ in the TLS protocol that a middlebox can read, even if it's explicitly not safe to meddle with it, gets meddled with. This rationale has driven QUIC work more than TLS 1.3, the QUIC WG even argued about whether to have a single unencrypted bit (the spin bit) in their protocol because they concluded middleboxes would undoubtedly tamper with it even though that's hauntingly stupid.

The long-term lesson has been that middlebox vendors (usually ostensibly "security" vendors) don't know anything about cryptography, or security, or networks, or possibly even about basic computer science ideas like counting. Their customers are often convinced that these idiots are protecting them, and the most we can safely do about that is try to discourage them from "protecting" anybody else.

Acual, real products your CIO can insist you spend money on to "protect" your network do things like run regular expression parsers over the opaque bytes in the X.509 certificate to look for malware, or lazily copy the random bytes from an attacker's packet into the "random" bytes of their own packet and are then surprised that all the cryptographic security doesn't work ...

What's the alternative if you want to be able to handle DDoS attacks? Something like OVH's VAC?