Rich Salz, Akami, OpenSSL Developer
TLS 1.0 was a slight modification of the original SSL protocol by Netscape, published in January 1999. Basically the same as SSL3 - it is bad, it is weak, it has no good ciphers and it's still in wide use.
TLS 1.1 came out in April 2006. It would be great to kill both TLS 1.0 and 1.1 off - but it's just too hard.
TLS 1.2 has been around since August 2008. Since then, there's been a bunch of new RFCs and algorithms from all over the world.
TLS 1.3 was approved in October 2015 in IETF.
Background on IETF: If it doesn't happen over email where everyone can see it, it didn't happen. It is divided into areas like Security, Operations, DNS, etc - each area has area directors and working groups and working group chairs. Very well laid out process, very egalitarian.
The working groups work by consensus - they demonstrate by humming, so people can't be singled out by raising hands or doing a verbal roll call. Many documents now do their iterations in GitHub.
IETF also has RFC editors who make sure final revisions follow the consistent and correct format for an RFC.
TLS 1.3 had a few goals - encrypt as much of the handshake as possible, reduce the handshake latency - ideally to one or zero roundtrip for repeated handshakes, update record payload and make it more privacy friendly.
Only uses ECDH and DHE (but nobody will use DHE - too expensive). All connections have perfect forward secrecy. Most things are encrypted (SNI is not). The most common curves will be NIST P-256 or X25519.
There will be improvements to bulk encryption. Three cipher types and two variations: ChaCha220/Poly1305, AESGCM128(256) and AESCCM 128 (256). The cipher lists and choices were just getting too long and mistakes were being made. these are the ones you need. The cipher suite no longer specifies key exchange or authentication mechanism - they are negotiated now.
The bulk encryption ciphers chose are all modern, secure and AEAD-only - in addition to confidentiality, you also get integrity (authenticity).
Authentication improvements: DSA was removed, RSA was kept and prefers RSA-PSS over PKCS #1.5.
There was general cleanup, like the removal of renegotiation (ie export crypto). Almost every message now has extensions: OCSP or Certificate Transparency stapling on server and client side. There is now padding at the TLS layer (this was slightly controversial). There is only one hash mechanism: HKDF (RFC 5869) and it's used consistently (and correctly). They've done cryptanalysis and attack events, found issues and fixed them. There will be no SHA. Does that mean SHA3 is no good? No, there were just concerns about performance and newness when TLS 1.3 work started.
SHA will still be around in certificates, though even SHA1 is being rapidly phased out.
Renegotiation is gone. There were many use cases: request client cert, "step-up" crypto algs and re-key. It was buggy and unclean and a source of problems. Only strong crypto is available.
There is allowance for session resumption. It prefers sessions over tickets. Sever can send session information at any time and the session is like PSK. PSK is like session resumption. If you're reconnecting, send data with the resumption :-) This gets you O-RTT - Zero Round Trip Tickets.
0-RTT: client connects, C&S do the ECDHE dance. Client remembers the server's key share. Next time, client reconnects and sends data encrypted with that key. This helps to avoid an extra round-trip with less latency. This makes your web faster and then we can all make more money.
0-RTT has a big butt... there is no PFS with early data. That data can be replayed elsewhere (GEt is idempotent). Nobody was really listening to these concerns until Colm@Amazon spoke and posted two weeks ago. No everybody's trying to figure out what to do. We want to do the right thing, but one of the primary goals was to improve performance - and browser vendors will use it anyways.
TLS 1.3 status is very close to IESG review. Chrome and FF and some others are at Draft-18. Draft 19 had minor changes, Draft 20 is incompatible.
The World's Most Unfortunate Wedding Monogram - Some couples look for a sign that their marriage will last. This isn't it. Thanks to Ruth H. for the initial discomfort. Note from john: For thos...