For actually understanding the RFCs, I've found it useful to crack open wireshark and then look at an actual TLS connection, and then cross reference the RFC to figure out what's going on. It makes everything more concrete in my opinion.
Most importantly TLS 1.3 _always_ starts by the two parties setting up a secure encrypted connection, and only then is any effort expended on trying to figure out who anybody is, whereas in earlier versions these elements happen somewhat simultaneously.
A TLS 1.0 guide was pretty helpful in understanding TLS 1.2, but a TLS 1.2 guide is probably just misleading for TLS 1.3
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. The only other protocol I've seen do this is obfuscated BitTorrent, using a deliberately short keylength and RC4, where the goal was not protection from MITM but to resist traffic analysis and blocking by making essentially all of the traffic look completely random. Meanwhile, TLS 1.3 still retains the plaintext record headers and framing from previous versions.
(One thing that I've always wondered about and never gotten a good answer is the fact that as far back as SSL 2.0, and presumably 1.0, there seemed to be no attempt to make the whole protocol encrypted, but instead the messages were very identifiable. Why not? One would think that a protocol designed to conceal data should itself be hard to distinguish from random noise.)
If someone knows of a high-level document about 1.3 that goes through the handshake process and differences with 1.2, that would be a great reference to have!
I mean, they take significant effort to devise these standards and write them up, presumably with modern tools, AND THEN force weird typewriter CSS upon them? It looks awful. I can't understand it.
https://tools.ietf.org/rfc/rfc793.txt
Plain ASCII text is a very compatible format, and probably will be for a very long time. For example, if you were to pipe this to a TCP socket on modern printer on port 9100 unchanged, it’ll likely print out roughly correct.
If there's a zombie apocalypse and we end up raiding the computer history museum for 80 column line-printers, sure, it makes sense to select the ASCII version to make print outs so that we could rebuild the internet.
But for the HTML version? Come on! Freshen it up a bit.
Imagine you've lost most of web technology after a nuclear apocalypse or something and have to recreate it from specs. You have no software guaranteed to render HTML correctly and completely. (We don't have it even now BTW.) It's like bootstrapping a compiler toolchain on an entirely new architecture. You have to start with assembly, and it looks awful.
