Since I am at the source of the original quote, I might as well respond...
Technically, forward secrecy is overhyped because it is recommended almost everywhere. In some contexts it makes sense and is a valuable property. In many other contexts it makes less sense and, while harmless from a security point of view, it may induce performance-related issues.
Suppose that you have two systems that want to exchange confidential data over an insecure network. This is the context of the TLS protocol. At some point, the data is encrypted with a secret key derived from the key exchange protocol used in the TLS handshake. Forward secrecy is a property that says, basically, that once the exchange is over, the involved parties do not keep around all the secret information that allows decryption: the data has been encrypted on the sender side, and decrypted by the recipient, and nobody (except the attacker, of course!) needs to decrypt it again, so the encryption key can be dropped. If the TLS client and server use the RSA key exchange, then the protocol is not forward secure, because the RSA decryption key is the server's long-term key, the one corresponding to the public key in its certificate, and these will live for as long as the certificate itself, usually months or years.
In that kind of situation, a non-forward secure key exchange can be exploited by an attacker if that attacker records the encrypted session, then later on manages to compromise the server to obtain the decryption key. This assumes that the attacker can somehow predict that he will be able to compromise the server at a later date, making it worthwhile to record encrypted sessions. This is not plausible in many situations involving for instance Web browsers talking to Web servers: the attacker simply does not know when or if he will get access to the server, and if the goal is to obtain (for instance) credit card numbers, the attacker won't bother to record previous sessions; he will simply plunder the server-side database, to which he will have good access once the server itself is compromised.
Notwithstanding, there are real-life contexts where forward secrecy is very useful; one of them is typically end-to-end encrypted messaging systems. A number of characteristics make forward secrecy highly desirable for such systems:
The total amount of encrypted data is much smaller than typical Web-browsing sessions (let's face it, today's Web is fat). Moreover, in some messaging systems, encrypted messages are already recording by servers that manage the transport, for asynchronous delivery.
Past conversations are interesting to attackers, and not necessarily made available to them by virtue of compromising one device (it depends on the system's strategy with regards to caching).
Group conversations imply group management, and, in particular, ability to exclude a former group member from subsequent discussions; this inherently calls for some sort of forward secrecy ("ratcheting", in modern parlance).
My point, though, is that the blanket recommendation for forward secrecy everywhere is "a bit overhyped", because it is, indeed, a blanket, universal recommendation, marketed as an unavoidable requirement in all cases, while many situations don't need it.
On the negative side, here is a performance issue that arises from the universal forward secrecy requirement. In TLS 1.3, forward secrecy is systematically enforced. Suppose that some small embedded device must talk to a server with mutual, certificate-based authentication. Suppose also that elliptic curve cryptography is used. The following will happen:
- The client generates a new ECDH key pair, i.e. a random integer a, and the curve point aG (for the conventional generator G).
- The server also generates a new ECDH key pair (b, bG).
- The server signs its public part bG; the signature will use ECDSA or EdDSA, and involves computing a multiplication of the generator G with a new scalar.
- The client verifies the signature. This requires performing two point multiplications, one of these points being the generator G, the other one being the server's public key. There are tricks to somehow mutualize some operations in these two point multiplications, but they need extra RAM, always a scarce resource in embedded systems.
- The client terminates the ECDH key exchange by multiplying the received bG with a.
- The server also terminates the ECDH key exchange by multiplying the received aG with b.
- The client must itself compute a signature with its own long-term key, so that the server knows that it talks to the right client.
In total, the client will need to compute five point multiplications, three of which being on the conventional generator G (since that generator is known in advance, this allows some optimizations, so multiplications of G are a bit less expensive than multiplications by a freshly received point). The cost on the server is similar.
Now, compare that with TLS 1.2. With TLS 1.2, all of the above can be done in about the same way (encoding of messages differs, but the cryptographic result will be the same); this would use an "ECDHE_ECDSA" cipher suite (ECDHE key exchange, signed by the server with its ECDSA private key). However, TLS 1.2 also offers "ECDH_ECDSA" cipher suites, without the final "E" of ECDHE (the one that means "ephemeral"). In the ideal case, what happens is the following:
- The server has a long-term EC key pair (b, bG). The public part (bG) is in its certificate, i.e. has been computed at key generation time.
- The client also has a long-term EC key pair (a, aG), with aG encoded in its certificate, again a key generation time.
- The client and the server send to each other their certificates.
- The client computes a(bG) as the premaster secret for the TLS connection (the actual encryption keys will be derived from the premaster secret with some HMAC-based function that also includes the random values exchanged during the handshake).
- The server computes b(aG) as the premaster secret for the TLS connection.
And that's it. The client and server now have to compute a single point multiplication each. This is called the "static-static Diffie-Hellman".
The static-static Diffie-Hellman key exchange is not allowed in TLS 1.3, because it is not forward secure. Modern implementations of elliptic curve cryptography are fast, and any decent server can certainly compute five point multiplications for each client without breaking a sweat; a decent x86 CPU can do 30000 point multiplications per second with a single core! However, on the client side, things may differ: a very small embedded system, e.g. an ARM Cortex M0+ clocked at 5 MHz or less (to save power), would need close to one second for each point multiplication. For such a client, a multiplication of the cost by five is certainly not negligible, and can be the difference between "a non-forward secure connection" and "no encryption at all because the forward-secure exchange is too expensive". Regardless of how much indispensable you think forward security is, lack of encryption is certainly not an improvement over non-forward-secure encryption.
In that sense, TLS 1.3 is more hostile to small embedded systems than TLS 1.2, and this is for the sake of mandatory forward security, even in cases where it does not bring any actual advantage. This is what I call "a bit overhyped".
