[tptacek]

It's a pretty good roundup. Some additional notes:

1. TLS 1.3: The biggest news regarding TLS 1.3 is that the RSA-based handshake has, at last, been evicted from TLS. This despite industry complaints that eliminating TLS RSA would cause problems, especially in the finance industry, for companies that need the ability to monitor the plaintext of TLS connections on their networks. The kerfluffle led to one of the all-time great exchanges on the TLS working group:

https://www.ietf.org/mail-archive/web/tls/current/msg21278.h...

TLS 1.3 is the first of what I think will be many steps towards the eventual deprecation of RSA in most applications. It's difficult to implement and deploy RSA safely, compared to the elliptic curve alternatives, and because we've come to demand forward secrecy from our protocols, RSA's ability to easily encrypt directly as well as sign has lost its luster.

2. PQ: I don't have much to say about this (I'm a QC skeptic, though I try to keep up with the underlying algorithms here), but would note that Google has since withdrawn the CECPQ1 experimental handshake from Chrome (not for any deficiencies, but simply because it was a temporary experiment). I guess I'd say: don't deploy new PQ crypto in new designs yet.

3. Backdoored Diffie-Hellman: The next two subjects in the round-up really read more like one section. Both the papers Bonneau cites are great and worth reading directly. The RFC 5114 thing seems like one of those "don't attribute to malice what can better be attributed to incompetence" sort of deals, particularly in light of the DH survey paper --- it's hard to blame NSA for implementations that don't check incoming public keys for validity. The tables in the middle of the paper give a good sense for how infrequent the attack they're talking about occurs on real hosts on the Internet, but, be that as it may, it's embarrassing that things like Exim were not only using the DSA DH parameters but also not checking incoming keys. For what it's worth: these attacks are in both Set 5 and, in a setting much closer to what the DH survey paper did, Set 8 of the cryptopals challenges. It's a neat attack, and also very applicable to ECDH.

4. I can't make myself care about DKIM.

5. Bonneau has a great list of practical attacks here; in particular, if you haven't read the DROWN paper, you're really missing out. If you've done set 6 of the crypto challenges --- http://cryptopals.com/sets/6 --- this is like Stunt Bleichenbacher, exploiting the malleability of RSA ciphertexts in multiple ways to get handshake material to function simultaneously in two very different protocols.

6. TLS/HTTPS: It took an insane, absurd amount of time to get Curve25519 standardized, especially relative to the benefits of having a fast, trustworthy curve that doesn't (in TLS) require point validation (mitigating the ECDH version of the attack against Diffie Hellman described above). The IETF basically ran an Olympic-level event in bikeshedding, this time. Crypto standards groups are evil, intrinsically, and should be avoided.

[bogomipz]

>"This despite industry complaints that eliminating TLS RSA would cause problems, especially in the finance industry, for companies that need the ability to monitor the plaintext of TLS connections on their networks"

How do they monitor plaintext of TLS? Do they "man in the middle" this traffic? Can you elaborate? Is this a compliance issue or sorts?

[wolf550e]

Since they have the key for their own certificate, they can man in the middle forward secret connections too (these days, ECDHE). By supporting only non-PFS RSA key exchange with TLS 1.2, they had the ability to retroactively decrypt traffic without doing full man in the middle. Maybe they mirror a port on a switch and run an IDS/antivirus that decrypts the traffic and analyzes it. Maybe they log all traffic for a while and want to decrypt it only if needed.

In any way, the solution someone came up with was to do Diffie Hellman but reuse the ephemeral key (make it static) and share it with the decryption box. This turns (EC)DHE into not forward secure key exchange. The client can notice this happens because the server will reuse the DH key. I didn't hear about any browser planning to warn the user about this. The ssllabs tester will complain.

[technion]

If you are using a non-forward secrecy supporting implementation, such as RSA, the SSL key on the server is all that's required to be able to decrypt the conversation.

That's why you can use Wireshark in the manner described here, by installing the SSL key on your client machine, and decrypting the whole session:

https://support.citrix.com/article/CTX116557

You'll note the article warns, it won't work with DHE. Similarly, it won't work with ECDHE. Modern forward secrecy ensures that even with the key, an attacker is constrained in their ability to decrypt the ciphertext.

I can only assume the industry request was based on running this sort of thing at a larger scale.