Systems Approach As we neared the finish line for our network security book, I received a piece of feedback from Brad Karp that my explanation of forward secrecy in the chapter on TLS (Transport Layer Security) was not quite right.

This is a perennial concern for me – that I will get something wrong in my explanations of security because I have not lived and breathed the field the way a true security expert would.

A lot of my writing is based on my reading of relevant RFCs, which are not always the easiest going for a non-expert, but can usually be considered authoritative. I spent enough time with the TLS RFCs to pick up the fact that there is a tradeoff between using “0-RTT” data (data sent along with the first TLS handshake message before the handshake completes) and forward secrecy. I went back to the RFC to check my facts, but forward secrecy is never really defined in the RFC; other sources, however, confirmed that my initial effort to explain the issue had missed the mark.

My next step was to see if a search query might get me somewhere, and I was very pleased with the result. I recognize that this is the sort of question one might take to their preferred LLM, but this is exactly the sort of subtle issue where I would not trust the LLM’s answer – I needed an authoritative reference. As it happened, I got to an authoritative reference directly from DuckDuckGo (my default search engine): it was a discussion among contributors to the upcoming revised version of the TLS RFC that tackled this exact issue. In fact the explanation will be clearer in the new RFC (due for publication soon).

The reason that 0-RTT data may not have forward secrecy is rather subtle, but what it comes down to is that the encryption key used for 0-RTT data is derived from a secret that may be long-lived (up to several days). This contrasts with the session key that is derived in a full TLS handshake using ephemeral Diffie-Hellman; that key is unique to the session, depends on no long-lived secrets, and is never re-used.

But the use of a relatively long-lived secret to create the session key for 0-RTT data means that an attacker could potentially save a copy of the 0-RTT data, and then later compromise the long-lived secret that was used to derive the session key. The essence of forward secrecy is this: There should be no long-lived secret which, if later compromised, would allow an attacker to decrypt the session.

One source of the confusion in the original RFC is the fact that some implementation strategies can avoid the use of long-lived secrets with 0-RTT data. However, the protocol provides no way for a client to determine what implementation strategy has been employed at the server, and so the RFC argues that clients must expect no forward secrecy for 0-RTT data. See the discussion noted above and the latest internet draft for more detail.

As a sort of experiment, I went to ChatGPT to see if I could learn anything further. While I can say that I found nothing wrong with the answers it gave me, I didn’t get the level of insight that the discussion among RFC contributors gave me. I also found myself going back to the RFC again to see if I believed what ChatGPT was telling me, which might be a “me issue”, but given the known problems with LLMs making things up, seems reasonable. And that’s before I even get to the climate impact of using LLMs to do the work of search engines.

A classic systems problem

More interesting than the relative merits of search versus LLMs, to me at least, was the way in which this detailed examination of TLS illustrated our position that network security is a systems problem. Making tradeoffs is at the heart of system design, and here we have a very clear tradeoff between optimizing performance (save an RTT in getting data flowing between client and server) and an aspect of security.

As with many systems problems, there is a complex set of moving parts that interact to produce the overall system behavior. Some applications may care about forward secrecy, some may not; it depends on your threat model. Some applications may be very latency-sensitive, others less so. Thus there is no single right answer, but the protocol design allows different application designers to make different choices.

We allocated an entire chapter to TLS in our new book because of how well it illustrates the systems approach. In addition to the performance-security tradeoff just discussed, TLS contains quite a comprehensive set of mechanisms to allow: authentication of one or both parties in a session; confidentiality of data; integrity; and protection against a range of attacks including man-in-the-middle, protocol downgrade, and replay attacks.

Most of these mechanisms can be configured in various ways to make different tradeoffs in a large design space. In many cases, the mechanisms found in TLS 1.3 have been built in response to weaknesses discovered in earlier versions of TLS. If you want an illustration of how a secure system can be built by assembling and configuring a set of component parts, and the tradeoffs inherent in building such a system, you can hardly do better than TLS.

Finally, the system story does not stop with TLS. Applications that use TLS have to make their own system design choices; for example, an application may choose to use 0-RTT data, overriding the safer default behaviour in TLS. Doing so requires the application to deal with the forward secrecy risks, along with possible replay attacks (another subtle issue in the design of TLS).

Similarly, there is a decision to make about what transport runs below TLS, with QUIC offering a number of benefits relative to TCP. Even decisions about the UI of a browser, such as the use of a padlock icon to show you when a connection is secured by TLS, are part of the overall system design.

As we have said before, it is easy to be overly focused on the building blocks of security such as cryptographic algorithms. But a systems approach takes into account competing design goals, including both a range of threat models and performance considerations, when deciding how to assemble those building blocks into a specific solution.

When I look at the improvements in TLS, HTTP, and QUIC over thirty years since the first secure socket layer implementation, it’s an impressive story of a complex, evolving system. And I am much happier to have learned that story from the perspective of the people building the standards than from an LLM. ®