Reading RFCs for Security Research

I recently needed to review an RFC for a protocol while working on some security research. I wrote a short guide based on my notes and other resources from the internet.

Reading RFCs for Security Research

RFCs—Request for Comments—are more than just dry technical documentation, and for security research they can be very useful at times. This is mainly because they contain blueprints of how systems and protocols should behave. By comparing these specifications with how things are actually implemented, you can often spot security flaws, logic gaps, or outright vulnerabilities in whatever component you are testing. I decided to write this guide since I was reviewing an RFC while while looking at a open source software and how its implementing a file format.

Why read RFCs

Understanding how protocols are supposed to work—according to their designers—is key to identifying where implementations go wrong. Many vulnerabilities arise not from the protocol itself, but from deviations in how it’s put into practice. By studying RFCs:

• You can understand the intended design, assumptions, and limitations of a technology.
• You can spot inconsistencies across implementations that might introduce bugs or security issues.
• You can gain insight into edge cases, which are often sources of subtle or critical vulnerabilities.
• You can master foundational protocol behavior and compare that with real world implementations to find flaws.

Espically if you’re doing work in areas like protocol fuzzing, implementation testing, or exploit development, RFCs can be your primary source of truth.

Structure of an RFC Document

Here is an example of an RFC - https://datatracker.ietf.org/doc/html/rfc2616

RFCs follow a relatively standardized structure. Understanding this layout helps you zero in on the sections most relevant to your research:

• Abstract: A brief overview of what the RFC covers.
• Introduction: Background and context—why this document exists.
• Terminology: Defines key terms used throughout the document.
• Protocol Overview / Main Sections: Detailed technical explanation of how the protocol or system is supposed to work.
• Security Considerations: Highlights expected security behaviors, risks, and best practices.
• IANA Considerations: Information about any protocol numbers or registry updates.
• References: Documents or prior RFCs this one builds on.

There may also be appendices, examples, or acknowledgments. Some of the most security-relevant material is often buried in examples or footnotes—don’t skim these!

Different Types of RFCs

Not all RFCs define internet standards. It’s important to know what type you’re looking at:

• Standards Track (Proposed Standard, Draft Standard, Internet Standard): These define how something should work and are the most important for research.
• Best Current Practice (BCP): Documents procedures, guidelines, or operational best practices.
• Informational: Often used for documentation or research that isn’t meant to be a standard.
• Experimental: New approaches or ideas not yet ready for standardization.
• Historic: Deprecated or replaced standards—still valuable for understanding legacy systems.

Each RFC has a “Status” field near the top. Always check it—if the RFC has been obsoleted, there’s likely a newer one you should be reading.

How to Read an RFC Effectively

Here are some techniques to read RFCs effectively to find interesting points:

1. Skim First, Then Go Deep

Read the abstract, intro, and table of contents before jumping into the full content. This gives you a rough mental model of what the RFC is about. You can also use LLMs such as ChatGPT to summarise sections and comprehend sections better.

2. Learn the Language of Requirements

RFCs use very specific terms to indicate the strength of a requirement, defined in RFC 2119:

• MUST / MUST NOT – Absolute requirements.
• SHOULD / SHOULD NOT – Strong recommendations, but with potential exceptions.
• MAY / OPTIONAL – Implementation is free to choose.

These words can hint at flexibility or rigidity in implementations—key areas where security bugs can creep in. You can take notes of these points and check if the codebase or software you are auditing is implementing these points correctly. Here is an example with RFC 2616 (http://datatracker.ietf.org/doc/html/rfc2616#section-14.13) which takes about content-length Applications SHOULD use this field to indicate the transfer-length of the message-body. During my HTTP Request smuggling research, i found multiple backend libraries deviating from RFC specifications when dealing with both the Content-Length and the Transfer-Encoding header. - Snyk HTTP Request Smuggling

3. Focus on Security Considerations

The “Security Considerations” section isn’t just filler—it’s often where the protocol’s assumptions and limitations are made explicit. Pay close attention to:

• How the protocol expects to handle authentication or encryption.
• Any known attack vectors the designers are aware of.
• Assumptions about trust boundaries or error handling.

See an example with RFC2616 https://datatracker.ietf.org/doc/html/rfc2616#section-15 which gives you a wealth of attack vectors such as Location Headers and Spoofing and Content-Disposition Issues for the HTTP/1.1 protocol.

4. Compare With Real Implementations

RFCs define how things should behave—but reality doesn’t always follow. Compare the spec to:

• Open source implementations (e.g. OpenSSL, curl, BIND).
• Closed-source software if you’re reverse engineering or fuzzing.
• Network traffic captures (using Wireshark) to spot deviations.

Other tips

• Trace Protocol Flows: Follow step-by-step examples in the RFC to see how state is supposed to change. Can an attacker disrupt or manipulate this?
• Explore Edge Cases: Are there “undefined behaviors” or MAY clauses? These can hint at dangerous implementation variability.
• Don’t Skip Deprecated Specs: Older RFCs might still be implemented in the wild. These legacy behaviors are often goldmines for bugs.
• Check for Ambiguities: If the RFC is vague or open to interpretation, that might be interesting, Different vendors may implement it differently, creating inconsistencies or bugs.

Use Tools to Speed Up the Process

When comparing an old version of an RFC with the newer version, the following tools might come in handy:

• 📄 rfcdiff: Helps you compare two versions of an RFC and spot changes. (https://tools.ietf.org/rfcdiff)

• 🔍 Errata Search: Check IETF’s Errata page to see if there are known issues with the RFC you’re reading. (https://www.rfc-editor.org/errata)

• 📚 RFC Index: The full index at rfc-editor.org helps you explore related or newer documents. (https://www.rfc-editor.org/)

• ✍️ PDF & Markdown Tools: Tools like Pandoc can help convert RFCs to formats you prefer for annotation.