Please Don't You Take Away My Perfect Forward Secrecy

Opinions expressed in this commentary are solely those of MRD.

Decisions having ubiquitous consequence with the way the Internet or services thereon work happen all too often without almost all who use the Internet even knowing. Ignorance doesn't mean not caring though. It more likely means blissfully unaware; and in some cases, to our own detriment. Hence this blog posting, and for the chance that even a single reader may benefit from learning a bit more about what happens behind the scenes. And perhaps motivate them to seek more information on its content, the Internet, how it works, and when key players make consequential changes to innerworkings.

We're talking about the stuff WE ALL use EVERY time our browser connects to sites on the Internet requiring secure connections, within which sensitive data is transmitted. You know... that HTTPS stuff (S is for security). Or at least, those sites that should be using HTTPS, TLS, and key agreement (e.g. Diffie-Hellman key agreement). The latter two are implementations and applications of mathematics respectively for the former, and the topic at hand.

Key (Diffie-Hellman) agreement is necessary for two computers over a network (e.g. the Internet) to transmit data securely. As it happens, there are two types - ephemeral and static. The former produces a new key for each session of data transition, and thus provides what's called PFS (Perfect Forward Secrecy). Meaning should any session's key be compromised and security of the data along with it, all other secure sessions should still be securely OK. The latter, static... any compromise means henceforth, your cover is blown. That is if the key is not regenerated, which would be unlikely.

If what I understand is correct, the IETF Internet Engineering Task Force are considering reintroducing ciphersuites with static key agreement back into the TLS specification, so as to appease the network monitoring industry into adoption of the specification, rather than ephemeral key agreement having PFS. As this would require no change to the client-side of key agreement, and prior versions of TLS have such static key agreement ciphersuites, one would never know if they've PFS or not. And implications don't stop there. It invites other vulnerabilities, such as replay attacks.

This smells like yet another use case for distributed consensus key agreement. Although not plentiful, there has been such research. No doubt the monitoring industry is important and deserve a say in this matter. But reintroducing static key agreement ciphersuites back into a specification that's meant to be moving forward, simply seems a step backward.