The Internet Engineering Task Force (IETF) Request for Comments (RFCs) are required by RFC 2223, Instructions to RFC Authors, to have a section titled “Security Considerations” that is supposed to call out any special security implications relating to the protocol itself or to the networking infrastructure around it. Unfortunately, the requirements for this section as specified in RFC 2223 were neither instructive nor motivating:
All RFCs must contain a section near the end of the document that discusses the security considerations of the protocol or procedures that are the main topic of the RFC.
As a result, RFCs have disregarded the security implications of their topics, and managed to move right through the rigorous process with a few high level statements about authentication or securing of the transport channel. In fact, this situation was recognized in 2003 with RFC 3552, Guidelines for Writing RFC Text on Security Considerations:
All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section.
This was more motivating and informative for the time, but that was quite a while ago. The world is a pretty different place now so we still have more work to do when it comes to considering the broad range of security implications with each new standard we develop, even with guiding documents such as RFC 3552.
Enter Heartbleed. This experience provides a very interesting example of how we can still do better, even recognizing that the vulnerability was not caused by a fault in the standard itself. Heartbleed is the result of a simple coding error in one implementation of the standard, but it is also the case that the Security Considerations section of RFC 6520, TLS Heartbeat Extension, is a little flimsy:
The security considerations of [RFC5246] and [RFC6347] apply to this document. This document does not introduce any new security considerations.
(Where RFCs 5246 and 6347 define TLS and Datagram TLS, respectively).
Of course, warning about exploits based on coding errors in implementations is certainly not in the scope of any standard, and bugs are remarkably obvious after they are discovered when you are staring at the exact lines of code. However, as this was to be a heartbeat mechanism for the protocol that secures most of our communications across the Internet, a little more effort thinking through possible failure scenarios would have been time well spent.
In fact, the entire community had the opportunity to spend more time considering this section. This RFC had 4 Internet-Drafts (I-Ds), providing opportunities for comment between June 2010 and the publication of the RFC in February 2012. However, the Security Considerations section is the same in the final standard as it was in the first draft. A few more discussions about the use or possible misuse of the payload field could have resulted in the examination of the mailing lists. This would have possibly led the developer or code reviewer to analyze the code properly and maybe we’d be discussing something else right now.
A good example of how the Security Considerations section is evolving to consider the newest threats can be found in an Internet-Draft for the padding of TLS client hellos. Even though this I-D pre-dates the discovery of Heartbleed, it tries to consider the possibility of exploitation:
The contents of the padding extension could be used as a covert channel. In order to prevent this, the contents are required to be all zeros, although the length of the extension can still be used as a much smaller covert channel. Servers MAY verify that the extension is either empty or contains only zero bytes, in order to enforce this.
Will it be sufficient? I wish I knew. The only way to find out is after this draft moves through the standards process to an RFC and is eventually implemented. To be fair, many things will be different going forward due to the heightened attention after Heartbleed. However, it is still necessary to continue to raise awareness of possible security ramifications during the standard development process, and cautiously deliberate the content of the Security Considerations sections.
A note to Security Professionals: If all of this IETF jargon looks Greek to you, I invite to you consider joining the IETF Security Area mailing list or even attending an IETF meeting. The barrier to entry is low and the potential value of cross-pollination between the networking and security communities is high. There is still plenty of opportunity to make a difference as we push the industry forward.