How to Read RFCs

What Is an RFC?

RFC stands for Request for Comments. The name is a historical artifact from the late 1960s when the ARPANET was being designed and engineers literally asked each other for comments on proposed protocols. Today, RFCs are the authoritative specification documents for Internet protocols, formats, and procedures. They are published by the Internet Engineering Task Force (IETF) and maintained by the RFC Editor.

Every protocol you use daily - TCP, HTTP, TLS, DNS, DHCP - is defined in one or more RFCs. When you read that WPA3 uses SAE (Simultaneous Authentication of Equals), the cryptographic details live in RFC 7664. When someone says "TLS 1.3 removed RSA key exchange," the proof is in RFC 8446.

RFCs are not textbooks. They are specifications. The writing is precise, sometimes dry, and intentionally unambiguous. That precision is exactly why they are worth reading.

Anatomy of an RFC

graph TD
    subgraph "RFC Document Structure"
        A["Header Block
RFC Number, Title, Authors, Date"] --> B["Abstract
One-paragraph summary"]
        B --> C["Status of This Memo
Standards Track / Informational / Experimental"]
        C --> D["Table of Contents"]
        D --> E["Introduction
Problem statement and scope"]
        E --> F["Terminology
MUST, SHOULD, MAY per RFC 2119"]
        F --> G["Technical Sections
Protocol details, formats, procedures"]
        G --> H["Security Considerations
Mandatory since ~2003"]
        H --> I["IANA Considerations
Registry assignments"]
        I --> J["References
Normative vs Informational"]
    end
    subgraph "Status Types"
        K["Standards Track"] --> L["Proposed Standard"]
        L --> M["Internet Standard"]
        K2["Non-Standards"] --> N["Informational"]
        K2 --> O["Experimental"]
        K2 --> P["Best Current Practice"]
    end

The structure of an RFC document - every RFC follows this general layout with minor variations

The header block tells you the RFC number, title, authors, publishing date, and which organization produced it. Right below that is the abstract - usually a single paragraph that tells you whether this RFC is relevant to what you are looking for.

The "Status of This Memo" section is critical. It tells you whether this document is a Standards Track RFC (meaning it defines an actual protocol that implementations should follow), Informational (useful background but not normative), Experimental, or Best Current Practice (BCP). If you are trying to understand how a protocol works, you want Standards Track documents.

The terminology section references RFC 2119, which defines the keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY. These are not casual English. "MUST" means an absolute requirement. "SHOULD" means there may be valid reasons to ignore this item, but the full implications need to be understood. "MAY" means the item is truly optional. When you see "implementations MUST support AES-128-GCM," that is a hard requirement, not a suggestion.

Navigating RFC Tools

sequenceDiagram
    participant R as Researcher
    participant RE as rfc-editor.org
    participant DT as datatracker.ietf.org
    participant TI as tools.ietf.org

    R->>RE: Search by keyword or number
    RE-->>R: RFC text, metadata, errata
    R->>DT: Find working group drafts
    DT-->>R: Internet-Drafts, meeting notes
    R->>DT: Check RFC status and updates
    DT-->>R: Obsoleted-by, Updated-by links
    R->>TI: Read HTMLized version
    TI-->>R: Hyperlinked references, clean formatting
    R->>RE: Check errata for known issues
    RE-->>R: Verified and reported errata list

The three main RFC resources and what each one is best for

The primary source is rfc-editor.org. You can search by RFC number, keyword, author, or date range. The site hosts the canonical plain-text versions of every RFC, along with metadata, errata (corrections), and cross-references to related documents.

datatracker.ietf.org is the IETF's document tracker. This is where you find Internet-Drafts (documents in progress that may become RFCs), working group information, and the full history of a document from initial draft through publication. The datatracker also shows you which RFCs have been obsoleted or updated by newer documents - critical information because reading an obsoleted RFC without knowing about its replacement is a common mistake.

tools.ietf.org provides HTMLized versions of RFCs with clickable cross-references, which makes navigation much easier than raw text. It also provides diff tools for comparing RFC versions and a bibtex service for academic citations.

When you find an RFC, always check two things: (1) Has it been obsoleted? The datatracker page for any RFC shows "Obsoleted by" if a newer version exists. (2) Are there errata? Published corrections can significantly change the meaning of specific sections.

Reading ABNF Grammar

Many RFCs define protocol syntax using Augmented Backus-Naur Form (ABNF), specified in RFC 5234. If you have never seen ABNF before, it looks intimidating. It is actually straightforward once you learn a few rules.

ABNF uses rules of the form name = definition. The forward slash / means alternation (OR). Square brackets [ ] mean optional. Asterisks indicate repetition: *element means zero or more, 1*element means one or more, and 3*5element means three to five occurrences.

For example, from RFC 8446 (TLS 1.3), the ClientHello message structure is defined in ABNF-like notation:

uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2];

struct {
    ProtocolVersion legacy_version = 0x0303;
    Random random;
    opaque legacy_session_id<0..32>;
    CipherSuite cipher_suites<2..2^16-2>;
    opaque legacy_compression_methods<1..2^8-1>;
    Extension extensions<8..2^16-1>;
} ClientHello;

This tells you exactly what bytes appear on the wire. legacy_version is always 0x0303 (TLS 1.2 for backward compatibility). random is 32 bytes. cipher_suites is a variable-length list between 2 and 65534 bytes. You could write a parser directly from this definition.

RFCs for Wireless Security

graph TD
    subgraph "Authentication Layer"
        EAP["RFC 3748
EAP Framework"]
        EAP --> EAPTLS["RFC 5216
EAP-TLS"]
        EAP --> PEAP["RFC draft
PEAP"]
        EAP --> EAPTTLS["RFC 5281
EAP-TTLS"]
        EAPTLS --> TLS["RFC 8446
TLS 1.3"]
    end
    subgraph "Encryption Layer"
        TLS --> AES["RFC 5116
AEAD (AES-GCM)"]
        TLS --> CHA["RFC 7539
ChaCha20-Poly1305"]
        TLS --> HKDF["RFC 5869
HKDF Key Derivation"]
    end
    subgraph "Key Management"
        SAE["RFC 7664
Dragonfly / SAE"]
        FOUR["IEEE 802.11
4-Way Handshake"]
        SAE --> FOUR
        HKDF --> FOUR
    end
    subgraph "Network Layer"
        RADIUS["RFC 2865
RADIUS"]
        EAP --> RADIUS
        DHCP["RFC 2131
DHCP"]
        DNS["RFC 1035
DNS"]
    end

How wireless security RFCs relate to each other - authentication, encryption, key management, and network layers

If you are working with wireless security tools like the BLEShark Nano, these are the RFCs that matter most:

RFC 8446 - TLS 1.3: The current version of Transport Layer Security. This is relevant because WPA3-Enterprise uses EAP methods that run over TLS. Understanding the TLS handshake helps you understand what happens during enterprise WiFi authentication. At 160 pages, it is a substantial read, but Section 2 (Protocol Overview) gives you the critical flow in about 10 pages.

RFC 3748 - EAP: The Extensible Authentication Protocol framework. EAP is the authentication layer used in WPA2-Enterprise and WPA3-Enterprise. This RFC defines the request/response model, the identity exchange, and how EAP methods are negotiated. It is shorter and more accessible than TLS 1.3.

RFC 5216 - EAP-TLS: The most secure EAP method, using mutual TLS authentication with client and server certificates. If you are analyzing enterprise WiFi authentication, this is the method you will encounter most in high-security environments.

RFC 7539 - ChaCha20-Poly1305: An authenticated encryption algorithm used as an alternative to AES-GCM in TLS 1.3. Relevant because some WPA3 implementations negotiate this cipher suite.

RFC 5869 - HKDF: HMAC-based Key Derivation Function. This is how TLS 1.3 (and by extension WPA3-Enterprise) derives session keys from shared secrets. Understanding HKDF helps you understand why captured handshakes alone are not enough to decrypt traffic.

RFC 2865 - RADIUS: The authentication server protocol used in enterprise WiFi. When a device connects to WPA2/WPA3-Enterprise, the access point forwards authentication to a RADIUS server. This RFC defines that communication.

Why Specs Beat Blog Posts

Blog posts about protocols are useful for getting a quick overview. But they have three problems that RFCs do not:

Accuracy decay. Blog posts are written once and rarely updated. An article about TLS from 2018 might describe TLS 1.2 as "current" and not mention TLS 1.3 at all. The RFC, by contrast, has a clear status. If RFC 5246 (TLS 1.2) is obsoleted by RFC 8446 (TLS 1.3), that relationship is explicit and machine-readable.

Omission of edge cases. Blog posts simplify. That is their job. But the edge cases they omit are often the exact details that matter for security. The TLS 1.3 spec devotes entire sections to downgrade protection, 0-RTT replay risks, and certificate verification requirements. A blog post might mention "TLS 1.3 is more secure" without explaining why or what the remaining risks are.

No normative language. When an RFC says "implementations MUST reject," that is a testable, verifiable requirement. When a blog post says "you should probably check," that is advice. The distinction matters when you are evaluating whether a device or protocol implementation is correct.

Practical Reading Strategy

You do not need to read an RFC cover to cover on the first pass. Here is a practical approach:

First pass - 10 minutes: Read the abstract, introduction, and security considerations section. This tells you what the RFC does, why it exists, and what security properties it claims. If the security considerations section is short or vague, that is a red flag about the protocol's design maturity.

Second pass - 30 minutes: Read the protocol overview or architecture section. Most RFCs have an early section that gives a high-level description of how the protocol works. In RFC 8446, this is Section 2. In RFC 3748, it is Section 1.3. This gives you the mental model you need to understand the detailed sections.

Deep read - as needed: Now you can target specific sections based on what you need. If you are analyzing a handshake capture, read the message format definitions. If you are looking for implementation requirements, search for MUST and SHOULD. If you are evaluating security properties, read the security considerations in detail and follow the references.

Keep a note of RFC cross-references as you read. Most RFCs reference 10 to 50 other documents. You do not need to read all of them, but tracking which ones are normative references (required for understanding) versus informational references (background reading) helps you build an efficient reading list.

One last tip: the IETF publishes meeting proceedings and mailing list archives. When you want to understand why a particular design decision was made, the working group mailing list often has the discussion that led to it. The datatracker links to these archives from each working group page.

RFCs are freely available at rfc-editor.org. The BLEShark Nano captures the wireless traffic these protocols describe - reading the specs helps you understand what you are looking at.