At its root, the attack weaponizes unknown key share attacks by deploying them in the context of a TLS MITM. UKS attacks are a well-known but infrequently considered protocol vulnerability; the best documentation I know of them (thanks to smarter friends who pointed this out to me) is the STS paper from '99:
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=33A...
The basic idea is that protocols assume that if Alice and Bob agree on a key, Alice and Bob must both believe they've authenticated to each other. In reality, Mallory can often exploit that assumption. For instance, Mallory can negotiate a session with Alice and Bob, arrange to have the sessions arrive at the same key, and then replay Alice's messages on the connection to Bob.
The kernel of the attack in this paper is a UKS attack that exploits the differing assumptions of two different session authentication schemes that coexist in TLS. The first is the ordinary public-key exchange that people assume happens on every TLS connection. The second is the session resumption form, which skips the public-key exchange. The problem is that the first form is cryptographically bound to the certificates on the connection, but the second form is bound instead to the shared state that is computed by both sides of the connection and not explicitly to the certificates. An attacker can MITM Alice and Bob, synchronize their keys (by waiting for Alice to compute a key and send it to the MITM, unwrapping it, and resending it to Bob), kill the session, then MITM the session resumption that happens when Alice reconnects; the attacker has laundered their involvement in the session.
Aside: to me, the funnest part of the paper is the synchronization/UKS attack that happens in classic DH TLS (which is rarely used). Instead of unwrapping and resending Alice's key, Mallory can trick Alice into accepting a bogus DH group which reveals her key to Mallory. The researchers found that WinAPI' SChannel and Chrome/Firefox NSS were susceptible to malicious DH parameters, as were 12% of the top Alexa servers. Wee!
Why "rarely used"? Because most DHE TLS connections are Elliptic Curve DH, not classic DH. Elliptic curve groups are much scarier to validate than classic DH groups (where you really just care that the DH modulus is large and prime and the generator generates the whole group --- though ironically the authors found that this doesn't reliably get validated). As a result, TLS stacks require specific ECDH groups; you can't play as many games with them.
The downside (to me, not to you) is that the attack has limited impact. Basically, what this UKS attack mostly does is revive a session resumption attack Marsh Ray found a couple years ago. Alice can connect to Bob; Bob demands a client certificate from Alice. Mallory wants to connect to Bob, and so makes a connection to Bob, sends data, and then renegotiates TLS with a handshake replayed from Alice and Bob. Mallory can't read those messages or, for that matter, anything subsequent on the connection, but Mallory's data may be accepted by Bob, despite it not being authenticated.
'cperciva, 'pbsd --- I've given you a lot to work with here. Tell everyone else here how I got this wrong! :)