The background you want to understand the TLS 1.2 ciphersuite benefits:
TLS was designed and standardized before cryptography figured out the proper order of encryption and authentication, or, for that matter, that authentication was even required. It dates back to an era where designs based on what were best practices at the time often eschewed authentication (of plaintext or ciphertext) altogether; instead, designers assumed that because attackers didn't have crypto keys, they couldn't tamper with ciphertexts, because their decryptions would result in gibberish.
A few years after SSL3/TLS, it was widely understood that cryptosystems required authentication (the "gibberish decryption" defense is often just a speed bump). And then it was mathematically proven that there's a proper order to the two operations: cryptosystems should encrypt, then they should authenticate the ciphertext. Doing it this way (among other things) denies attackers the opportunity to conduct chosen ciphertext attacks, which in turn closes off a variety of side channels (such as error oracles, which were introduced in the symmetric crypto literature a few years after this).
The net result is that the old TLS ciphersuites are a mess with regards to encryption and authentication. They do authenticate, using HMAC (which is fine) in a generic composition. But they authenticate plaintext, which means attackers can play games with ciphertexts; one result of this was the Lucky 13 padding oracle attack.
AES-GCM and ChaCha20-Poly1305 are modern authenticated cipher constructions. They are conceptually very similar. Both are stream ciphers (and, in fact, both are designs based on the concept of "CTR [counter] mode"). Both use polynomial MACs instead of cryptographic hash MACs (you can think of a poly MAC as a thermonuclear CRC algorithm). AES-GCM is very fast in hardware (because it's a NIST standard that chipset vendors have optimized for). ChaCha20-Poly1305 was designed to be fast in software as well.
Another bit of backstory you might want to know concerns the italicized "very difficult" Langley used to describe software AES-GCM. AES-GCM uses a poly MAC that wants GF(2^n) multiplication and modular reduction. Fast software implementations of GCM rely heavily on lookup tables. Lookup tables entries are aggressively cached as they're hit, which makes the timing of software AES-GCM heavily dependent on specific bit values of secrets, which is dangerous.
> you can think of a poly MAC as a thermonuclear CRC algorithm
Funny you would put it like that. You can turn the regular CRC algorithm (which is essentially a polynomial division) into a secure Wegman-Carter authenticator (like polynomial-evaluation MACs): the secret key key2 would be an irreducible CRC polynomial, and the scheme would loosely be PRF(nonce, key1) + CRC(message, key2) (see Shoup [1]).
Wegman-Carter authenticators, unlike hash-based ones, are information-theoretically secure. This means that they resist an attacker with infinite resources. In a way, they're the analog of the one-time pad for authentication. They also predate hash-based authenticators by decades: the first secure construction of this kind of authenticator goes back to 1974 [2]!
Reading about djbs primitive making its way in to TLS, and all the hacks being made to TLS, reminded me of CurveCP[0] and makes me wonder whether its an idea worth revisiting.
For those interested in playing with Salsa20 & poly1305 authenticated encryption outside of TLS there's Sodium[1] which has trivial C and C++ APIs and is based on djbs Nacl[2]
I'd also refer people to Matt Greens post 'How to chose an Authenticated Encryption mode'[3]. There are some interesting alternatives out there like OCB (0.7 - 0.8 cycles/byte, free for FOSS despite patents, and more understandable for mortals).
I asked Phil Rogaway in person about OCB mode and he said it's free and usable for all nonmilitary uses, even for businesses. For more info about the specific license you can email him personally, he's a really nice and helpful dude.
OCB is neat; unfortunately, the patent means it's also become exotic. Lesser authenticated encryption have also become absurdly fast. Also: I dispute the idea that OCB is easier to understand than GCM.
Why? A 32-bit block counter allows for 256GB messages. As AEAD messages shouldn't be decrypted in a "streaming" fashion (lest one return unauthenticated plaintext), that seems more than sufficient.
(We don't have a good spec for composing AEAD operations for chunking large messages yet, however.)
A side issue for the maintainer of the website: for widths of 800px and below, the website has no padding at all on the sides, and up to around 880px and below the article's title is cut off on the left (only part of the S in "» TLS" is visible—the rest is cut off on the left).
TLS was designed and standardized before cryptography figured out the proper order of encryption and authentication, or, for that matter, that authentication was even required. It dates back to an era where designs based on what were best practices at the time often eschewed authentication (of plaintext or ciphertext) altogether; instead, designers assumed that because attackers didn't have crypto keys, they couldn't tamper with ciphertexts, because their decryptions would result in gibberish.
A few years after SSL3/TLS, it was widely understood that cryptosystems required authentication (the "gibberish decryption" defense is often just a speed bump). And then it was mathematically proven that there's a proper order to the two operations: cryptosystems should encrypt, then they should authenticate the ciphertext. Doing it this way (among other things) denies attackers the opportunity to conduct chosen ciphertext attacks, which in turn closes off a variety of side channels (such as error oracles, which were introduced in the symmetric crypto literature a few years after this).
The net result is that the old TLS ciphersuites are a mess with regards to encryption and authentication. They do authenticate, using HMAC (which is fine) in a generic composition. But they authenticate plaintext, which means attackers can play games with ciphertexts; one result of this was the Lucky 13 padding oracle attack.
AES-GCM and ChaCha20-Poly1305 are modern authenticated cipher constructions. They are conceptually very similar. Both are stream ciphers (and, in fact, both are designs based on the concept of "CTR [counter] mode"). Both use polynomial MACs instead of cryptographic hash MACs (you can think of a poly MAC as a thermonuclear CRC algorithm). AES-GCM is very fast in hardware (because it's a NIST standard that chipset vendors have optimized for). ChaCha20-Poly1305 was designed to be fast in software as well.
Another bit of backstory you might want to know concerns the italicized "very difficult" Langley used to describe software AES-GCM. AES-GCM uses a poly MAC that wants GF(2^n) multiplication and modular reduction. Fast software implementations of GCM rely heavily on lookup tables. Lookup tables entries are aggressively cached as they're hit, which makes the timing of software AES-GCM heavily dependent on specific bit values of secrets, which is dangerous.