Why this matters
If you ship a WebRTC product — a telemedicine consultation, an e-learning live class, a video-conferencing room, a contact-centre channel, a live-shopping floor, a remote-collaboration tool, or an AI voice-and-video agent — security is not a checkbox you tick during the security review. It is wired into every packet your engineers send and every line of SDP they exchange. A confident product manager, founder, or buyer should be able to answer four questions without flinching: what exactly is encrypted, where the keys come from, what an attacker on the signalling channel can and cannot do, and where end-to-end encryption (E2EE) stops being free and starts requiring application-layer work. This article answers those four questions for the non-network-engineer, and points the senior engineer at the right RFC sections to verify every claim.
What WebRTC encrypts, and what it does not
A WebRTC call moves three different kinds of bytes across the public internet, and the standard handles each one differently.
The first is the media plane — the audio frames and video frames that make up the call itself. Every one of those frames is wrapped in an RTP packet, encrypted with SRTP, and sent over UDP. SRTP is non-optional in WebRTC; the W3C specification calls it required, and there is no "off" switch in the browser API. Even if your application is a localhost demo running between two tabs of the same Chrome window, the media is still encrypted on the way through the UDP socket.
The second is the signalling plane — the SDP offers and answers, ICE candidate exchanges, and any application-level chat that sets up the call. WebRTC has no built-in transport for signalling: the application picks the channel — WebSocket, HTTPS, even a long-poll endpoint — and the standard tells the application that channel must be authenticated and confidential, which in practice means HTTPS or WSS. If the signalling channel is plaintext, an on-path attacker can rewrite the SDP, swap the fingerprint, and complete a man-in-the-middle attack on the DTLS handshake before the media even starts.
The third is the data channel — the optional RTCDataChannel for arbitrary application data, used by collaboration tools, multiplayer games, and file transfers. The data channel rides on the same DTLS association that keys SRTP, so it inherits the same encryption properties.
What WebRTC does not encrypt is anything that happens at the application layer above the browser API. If your app processes audio for transcription on a server before sending it to the other browser, that path is your responsibility to secure. If your app records a call to disk, the recording is plaintext bytes unless your code encrypts them. And if your call is routed through a Selective Forwarding Unit (SFU) — which is true for almost every conference of more than two people — the SFU sees the decrypted media unless you also deploy application-layer end-to-end encryption (SFrame, covered below). For the wider SFU picture, see SFU vs MCU vs Mesh: the three WebRTC topologies.
Figure 1. The three planes of a WebRTC call. SRTP encrypts media end to end between hops; HTTPS or WSS protects the signalling channel; the DTLS handshake that keys SRTP also carries the data channel. The SFU breaks "browser-to-browser" E2EE — closing that gap is what SFrame is for.
SRTP in plain language
SRTP, Secure Real-time Transport Protocol, is defined in RFC 3711, published March 2004 by Baugher, McGrew, Naslund, Carrara, and Norrman. It is a profile of RTP — meaning, an extension that adds three properties on top of the ordinary RTP header: confidentiality (the payload is encrypted), authentication (a small tag at the end of every packet lets the receiver verify the packet has not been modified), and replay protection (an index inside the packet stops an attacker from saving an old packet and re-sending it later).
The original RFC 3711 specifies AES in counter mode (AES-CM) for encryption and HMAC-SHA1 for the authentication tag. That combination is now considered dated. Modern WebRTC implementations prefer AEAD-AES-128-GCM and AEAD-AES-256-GCM, the Authenticated-Encryption-with-Associated-Data ciphersuites added to SRTP by RFC 7714 (December 2015). AEAD means encryption and authentication happen in one pass, with a single key, which is faster on modern CPUs and simpler to reason about. The W3C RTCRtpReceiver.getCapabilities('audio').codecs and the srtp-context settings inside libwebrtc show which profiles are negotiated; in 2026, GCM is the routine choice on every shipping browser.
SRTP itself does not say where the encryption key comes from. The key is negotiated by some other protocol, and SRTP just consumes the result. WebRTC's "some other protocol" is DTLS — and the wiring between them is use_srtp, the DTLS extension defined in RFC 5764.
Two things about SRTP that surprise non-network-engineers are worth surfacing:
The first is that the RTP header is not encrypted, only the payload. The sequence number, the timestamp, and the SSRC (synchronisation source identifier) are visible to anyone on the path. This is deliberate: the network needs to see those fields to do its job — pacing, jitter buffering, congestion-control feedback, see Bandwidth Estimation and Congestion Control in WebRTC. What is hidden is the content of the speech and the pixels of the video.
The second is that the authentication tag is short: typically 80 bits for audio (10 bytes appended to every packet) and 32 bits for video. Eighty bits is a deliberate trade-off — long enough to make forgery impractical, short enough not to blow the bitrate of a 20-millisecond audio packet. RFC 3711 explicitly documents this choice and the reasoning.
DTLS: TLS that survived a flight over UDP
DTLS, Datagram Transport Layer Security, is the version of TLS that runs over UDP instead of TCP. WebRTC needs UDP transport for media (TCP's head-of-line blocking would ruin real-time audio and video; for the wider rationale, see TCP, UDP, and the choice every streaming protocol must make), but it also needs the protections that a TLS handshake gives — mutual proof-of-identity, agreement on cipher suites, derivation of session keys — so DTLS is the natural fit. The current version is DTLS 1.3, RFC 9147, published April 2022; the prior version DTLS 1.2 (RFC 6347, 2012) is still in production but being phased out. Firefox's NSS library and Chromium's BoringSSL both ship DTLS 1.3 in 2026; the libwebrtc default flipped during 2025.
The DTLS handshake in a WebRTC call runs on the media path itself, not on the signalling channel. That is the property that makes the whole architecture work: as soon as ICE has nominated a candidate pair (a working address on each side, see NAT, firewalls, STUN, TURN, ICE: how WebRTC actually reaches a phone), the two endpoints exchange ClientHello and ServerHello UDP datagrams across that pair, agree on a cipher suite, do the key exchange, and finish — all over the same UDP socket the media will later flow through. The handshake takes one round trip in DTLS 1.3 (down from two in 1.2), so the cost of "encrypted" instead of "plaintext" media in a WebRTC call is one round trip's worth of setup latency and a few hundred bytes of bandwidth.
How DTLS keys SRTP
This is the moment the two protocols become one. During the DTLS handshake, both sides negotiate the use_srtp extension defined in RFC 5764. That extension lets each side advertise which SRTP profiles it can use (SRTP_AEAD_AES_128_GCM, SRTP_AES128_CM_HMAC_SHA1_80, etc.) and pick one. When the handshake completes, both sides do not directly use the DTLS application keys for SRTP. Instead, they call the TLS Key Material Exporter (RFC 5705) with a fixed label string and pull out a deterministic block of bytes from the DTLS master secret. That block is split into the SRTP master key and the SRTP master salt for the client-to-server direction, and another block for the server-to-client direction. Those two pairs are what the SRTP context uses to encrypt and decrypt every subsequent media packet.
What is elegant about this is that the SRTP keys never travel on the signalling channel. The signalling server never sees them. The SDP offers and answers do not contain them. They are derived locally on each endpoint after a DTLS handshake whose security depends on the endpoints' certificates, not on anything the signalling channel says. That property is what makes WebRTC strictly stronger than the older SDES (Session Description Protocol Security Descriptions) approach, which transmitted SRTP keys directly inside the SDP — and which the WebRTC specification explicitly forbids.
Figure 2. The DTLS-SRTP handshake. Keys for SRTP are derived from the DTLS exporter; the signalling channel never sees them. A 1-RTT DTLS 1.3 handshake adds roughly one round trip to call setup.
The fingerprint: how SDP binds the media path to the signalling path
If DTLS keys SRTP on the media path, and the signalling channel never carries the SRTP keys, then how does the signalling channel matter for security at all? The answer is the a=fingerprint attribute in SDP, defined in RFC 5763 (with the underlying mechanism in RFC 4572).
When a WebRTC endpoint generates its DTLS certificate (browsers do this automatically and disposably — a fresh self-signed certificate per RTCPeerConnection in the standard case), it hashes the certificate with SHA-256 and writes that hash into the SDP it sends out. The line looks like:
a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2
When the DTLS handshake later happens on the media path, each endpoint inspects the certificate the other side presented, computes the same SHA-256 over it, and compares to the fingerprint it received in SDP. If the two match, the endpoint is talking to the same party whose certificate fingerprint came over the signalling channel. If they do not, the connection is torn down.
That comparison is the entire identity check for a vanilla WebRTC call. It binds the media plane to the signalling plane: an attacker who can rewrite SDP in flight can substitute their own fingerprint, terminate the DTLS handshake on the attacker's side, terminate a second DTLS handshake to the real callee, and act as an invisible man-in-the-middle. Which is why the WebRTC specification requires the signalling channel to be authenticated and confidential — typically HTTPS or WSS. The fingerprint is the bridge; HTTPS is the guard rail that stops the bridge from being swapped out.
The cryptographic choice of SHA-256 is significant. RFC 8122 (which updates 4572) explicitly disallows MD5 and SHA-1 for this fingerprint in any new deployment; if you see a sha-1 fingerprint in a modern browser's SDP, the implementation is out of date. Modern Chromium and Firefox both default to sha-256 and refuse to negotiate weaker hashes.
A subtlety worth knowing: the certificate is self-signed and ephemeral. It is not issued by a public certificate authority, it has no DNS name in its common-name field, and it typically lives only for the lifetime of the RTCPeerConnection. The only thing it does is provide a public key whose hash is the fingerprint that gets compared. That is enough — because the actual identity check is delegated entirely to the signalling channel, which the browser already trusts because it served the page over HTTPS.
The threat model: what an attacker can and cannot do
RFC 8826, "Security Considerations for WebRTC", lays out the threat model in a level of detail no other media protocol matches. A short summary, with the practical implications for a product team:
A passive eavesdropper on the media path sees encrypted SRTP packets and learns essentially nothing about the call content. They can see the IP addresses, the rate of packets per second, the size of each packet (which leaks some information about the codec and the bitrate; voice-activity detection can be inferred from packet timing), and the unencrypted RTP header fields. They cannot read the audio or watch the video.
A passive eavesdropper on the signalling path, if the signalling channel is not HTTPS, sees the entire SDP — including the fingerprints. The fingerprints alone do not let them decrypt anything, because the SRTP keys are derived on the media path from the DTLS exporter and never appear in SDP. But the SDP contains the IP addresses, the ICE candidates, and the user identifiers, which leaks call-graph information.
An active attacker on the media path can drop, reorder, or inject packets. SRTP's authentication tag stops injected packets from being accepted as legitimate. The replay-protection window stops a saved packet from being re-played later. The worst the attacker can do on this path is denial-of-service — make the call unusable, but not impersonate either side.
An active attacker on the signalling path — the dangerous case — can rewrite SDP, swap fingerprints, and complete a man-in-the-middle attack as long as the signalling channel is not authenticated. This is the attack the RFC describes in §4.2 of RFC 8826. The defence is HTTPS for the page and HTTPS or WSS for the signalling endpoint. Without those, the entire DTLS-SRTP architecture collapses on the signalling channel: the media is encrypted between attacker and each victim, not between victims.
A malicious peer — the person at the other end of the call — can record everything you send them and replay it later, post the recording publicly, or feed it into a deepfake pipeline. SRTP cannot defend against this and neither can any media protocol; once you've decided to talk to someone, you have to assume they keep the bits.
A malicious SFU, in a multi-party call routed through a server, sees decrypted media because it terminates the SRTP context. That is the structural gap E2EE closes — covered in the SFrame section below.
A cross-origin attacker — a website that wants to silently turn on a victim's microphone and camera — is blocked by the W3C getUserMedia permission model. WebRTC's security architecture treats permission to access local media as the single most important consent gate, and the prompt-on-first-use model is a deliberate part of the threat-defence design.
Unknown key-share: a subtle attack worth knowing
A 2020 IETF document, RFC 8844, described an "unknown key-share" attack on DTLS-SRTP. The setup: a malicious user A who wants to convince user C that some audio actually came from user B negotiates a call with both B and C using the same fingerprint, and forwards B's media to C. C sees a valid DTLS handshake against a fingerprint matching what they expected, but the speaker is somebody else. The mitigation is the tls-id SDP attribute (RFC 8842) and a stronger external session identifier — supported in modern implementations, sometimes called the "self-signed certificate uniqueness" check. The attack is exotic in practice but worth knowing about if your product's threat model includes adversarial callees.
Figure 3. The WebRTC threat model in one picture. SRTP defends the media path against eavesdropping and tampering. HTTPS defends the signalling path against MitM via fingerprint substitution. SFrame is needed to defend against a curious or compromised SFU.
Identity: the part of the spec almost nobody deploys
RFC 8827, the WebRTC Security Architecture, also defines an optional identity layer on top of DTLS-SRTP, mirrored in the W3C WebRTC Identity specification. The idea is to make a WebRTC call cryptographically attributable across origins — meaning, if a user on acme.example calls a user on globex.example, each side can prove to the other (and to the browser) the identity of the caller as attested by a third-party identity provider (IdP), not by the calling website.
The mechanism: each endpoint loads a JavaScript snippet from its chosen IdP (Google, Mozilla Persona historically, an OAuth provider). The IdP signs the SDP fingerprint with a token bound to the user's identity at the IdP. The receiving side fetches the IdP's verification script, validates the signature, and is told "this fingerprint really belongs to alice@example.com". This is exposed in the browser as RTCPeerConnection.setIdentityProvider().
In practice, almost nobody ships this. The RFC 8826 acknowledgement section explicitly notes the IdP mechanism has not seen wide adoption. The reasons: most real WebRTC products live inside a single trust domain (the same company's app on both sides), so cross-origin identity is moot; the IdP loading model is intrusive and brittle; alternative identity stories (server-side authentication of the WebSocket signalling channel, JWT-bearer tokens passed through SDP a= attributes) cover the same ground with less ceremony. As of 2026, the IdP API is still in browsers but you can build a serious WebRTC product without ever calling it.
What people deploy instead
The pattern that ships in production: the application authenticates the user on the signalling server (OAuth, SSO, magic-link, whatever the rest of the product uses), then issues a short-lived JWT or similar token that the WebRTC client presents to the SFU before being allowed to publish or subscribe. The SFU enforces the policy — who can join which room, who can publish which track, who can talk to whom. The DTLS-SRTP layer below provides cryptographic protection of the media; the application layer above provides the identity story. LiveKit, mediasoup, Janus, Jitsi, and every commercial SFU vendor (Twilio, Dolby, Cloudflare, AWS IVS) document this pattern; the company-wide WebRTC architecture page at /services/webrtc-development reflects it too.
End-to-end encryption: the gap SRTP does not close
A two-person WebRTC call is end-to-end encrypted in the strict sense: only the two browsers hold the SRTP keys, and the only way for a third party to read the media is to compromise one of the browsers. A multi-party call, routed through an SFU, is not. The SFU terminates the SRTP context to read the RTP headers and forward the right packets to the right subscribers, so it sees decrypted media — at the very least, the RTP headers; in most implementations, the full payload for jitter handling and bitrate adaptation. From the user's point of view, "WebRTC is encrypted" is technically true and operationally misleading.
RFC 9605, Secure Frame (SFrame), published August 2024, is the IETF standard that closes this gap. SFrame encrypts each media frame before it is wrapped in RTP and SRTP, with a key the SFU does not have. The SFU sees encrypted frames inside SRTP packets, can read the SRTP headers, can forward packets, but cannot decrypt the payload. End-to-end encryption between participants becomes possible without sacrificing the SFU's ability to route — the SFU still does the forwarding, but it is forwarding ciphertext.
In the browser, SFrame is implemented on top of Insertable Streams (officially: WebRTC Encoded Transform), a Worker-based API that gives JavaScript access to encoded frames before they enter SRTP on the send path and after they leave SRTP on the receive path. Chromium has full support; Safari and Firefox are partial in 2026. Group-key management — who gets which SFrame key, how a key is rotated when a participant joins or leaves — is delegated to an application protocol; the typical 2026 choice is MLS (Messaging Layer Security), although bespoke key-management schemes are still common in production. Google Meet shipped SFrame-style E2EE in 2022; Zoom's WebRTC product shipped its own E2EE based on similar primitives; the major SFU vendors all expose E2EE hooks today.
For most products, the call is: routine conferencing — DTLS-SRTP is enough; regulated healthcare or finance — add SFrame; "no server can see my data" claim in marketing — add SFrame and document the key-management story.
Where Fora Soft fits in
WebRTC, conferencing, telemedicine, e-learning, contact-centre video, surveillance, and live shopping are Fora Soft's core verticals since 2005, across 239+ shipped projects. Securing the media plane is routine: every project ships DTLS-SRTP by default, every project terminates HTTPS at the signalling gateway, and every project audits the SFU configuration for token-bound room access. End-to-end encryption is a slightly different conversation: most live-shopping and consumer products do not need SFrame; telemedicine and regulated-finance products often do; e-learning sits in between, depending on jurisdiction. The pattern that scales is "DTLS-SRTP for transport security, JWT-bound authentication for identity, SFrame on top when the threat model requires E2EE through the SFU".
A common WebRTC security mistake
The single most common production failure we see when reviewing a WebRTC project is not in the media stack at all — it is the signalling channel running over plain WebSocket (ws://) instead of secure WebSocket (wss://). In testing the call looks encrypted: SRTP is on, DTLS handshake completes, the browser console reports a secure connection. The team checks the box and ships. In production, an attacker on the same Wi-Fi network or on a compromised intermediate hop can rewrite the SDP in flight, swap the fingerprint, complete two DTLS handshakes — one with each victim — and silently relay all media. The DTLS layer reports success on both sides, because the certificates do match the (substituted) fingerprints in the (rewritten) SDP. The defence is one character: wss://. RFC 8827 makes the requirement explicit; checking it should be the first item on any WebRTC pre-release security checklist.
Comparing the four key WebRTC security mechanisms
| Mechanism | What it protects | Where it lives | Required by spec | Typical 2026 status |
|---|---|---|---|---|
| SRTP (AEAD-GCM) | Media confidentiality, integrity, anti-replay | Media path, every RTP packet | Yes (RFC 8827 §6.5) | Universal; AES-128-GCM the default |
DTLS 1.3 + use_srtp | Key exchange for SRTP, peer authentication via certificate | Media path, runs once after ICE | Yes (RFC 8827 §6.4) | Universal; DTLS 1.3 default in libwebrtc since 2025 |
SDP a=fingerprint (SHA-256) | Binds signalling identity to media-path certificate | Signalling plane, in every offer/answer | Yes (RFC 5763, RFC 8122) | Universal; SHA-256 is the only modern hash accepted |
| HTTPS / WSS signalling | Authenticates the signalling channel, blocks fingerprint substitution | Signalling plane, the transport itself | Yes (RFC 8827 §4.2 — required) | Universal in well-built products; the most common misconfiguration in early production |
| mDNS host candidates | Hides local IPs in ICE candidates | Signalling plane, ICE only | No (de-facto) | Chrome/Edge/Opera since 2019; partial in Firefox/Safari |
| W3C Identity / IdP | Cross-origin identity binding via third-party IdP | Browser API, opt-in JavaScript | Optional (RFC 8827 §7) | Rarely deployed; superseded by JWT-bound app auth |
| SFrame (RFC 9605) | E2EE through an SFU; SFU sees only ciphertext | Application layer, on top of Insertable Streams | No | Chromium full, others partial; standard for regulated verticals |
Numeric example: the cost of "encrypted"
The standard objection to encryption is overhead. Let's compute it for a routine WebRTC audio-video call.
A 720p H.264 video stream at 1500 kbps, packetised into roughly 1200-byte RTP payloads, produces about 156 packets per second. SRTP appends a 32-bit (4-byte) authentication tag for video, so the wire cost is:
156 packets/s × 4 bytes = 624 bytes/s = 5 kbps of authentication-tag overhead
For an audio stream at 32 kbps Opus, 50 packets per second, with an 80-bit (10-byte) tag:
50 packets/s × 10 bytes = 500 bytes/s = 4 kbps of authentication-tag overhead
Encryption itself is in-place and adds no bytes — AES-CM and AES-GCM operate on the payload as-is. The total wire cost of "encrypted" vs "plaintext" is roughly 9 kbps on a 1.5 Mbps call, or 0.6 % of the bitrate. On CPU, modern x86 and ARM cores have AES instructions (AES-NI on x86, Cryptography Extensions on ARMv8); a single core encrypts hundreds of megabits per second, so the CPU cost on a phone is unmeasurable next to the cost of decoding the video. The one-time DTLS handshake adds one round-trip to call setup — typically 30–150 ms — and a few kilobytes of one-time bandwidth.
There is no production reason to turn encryption off in WebRTC. There never was. The standard refuses to let you anyway.
What to read next
- WebRTC explained without arcana — the wider WebRTC architecture and call lifecycle.
- DTLS, SRTP, TLS, mTLS for media — the encryption layer across streaming protocols, including non-WebRTC contexts.
- SDP offer/answer in depth — where the
a=fingerprintline lives and how the offer/answer dance handles certificate rotation.
Call to action
- Talk to a streaming engineer about your WebRTC project: contact Fora Soft.
- See our case studies in conferencing, telemedicine, and live shopping: www.forasoft.com.
- Download the checklist WebRTC Security Pre-Flight (8-area, 28-item checklist for verifying DTLS-SRTP, fingerprints, signalling encryption, mDNS, and SFrame before release): Download PDF.
References
- RFC 8827 — WebRTC Security Architecture, Rescorla, January 2021. Standards-track. The authoritative description of the WebRTC security model — §6 (Communications security), §7 (Identity), §4.2 (signalling integrity). Tier 1; used for every normative claim about what WebRTC requires.
- RFC 8826 — Security Considerations for WebRTC, Rescorla, January 2021. Standards-track. Threat-model document; §4.2 documents the signalling-rewrite man-in-the-middle attack referenced in this article. Tier 1.
- RFC 3711 — The Secure Real-time Transport Protocol (SRTP), Baugher, McGrew, Naslund, Carrara, Norrman, March 2004. Standards-track. Base spec for SRTP confidentiality, authentication, and replay protection. Tier 1.
- RFC 7714 — AES-GCM Authenticated Encryption in SRTP, McGrew, Foley, December 2015. Standards-track. Adds AEAD-AES-128-GCM and AEAD-AES-256-GCM to SRTP — the modern default ciphersuites referenced throughout this article. Tier 1.
- RFC 5764 — DTLS Extension to Establish Keys for SRTP (DTLS-SRTP), McGrew, Rescorla, May 2010. Standards-track. Defines the
use_srtpDTLS extension and the SRTP-keying derivation referenced in the "How DTLS keys SRTP" section. Tier 1. - RFC 5763 — Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using DTLS, Fischl, Tschofenig, Rescorla, May 2010. Standards-track. Defines the SDP fingerprint mechanism and the binding between signalling and media; cited for the
a=fingerprintsemantics. Tier 1. - RFC 9147 — The Datagram Transport Layer Security (DTLS) Protocol Version 1.3, Rescorla, Tschofenig, Modadugu, April 2022. Standards-track. DTLS 1.3 spec; cited for the 1-RTT handshake property and the cipher-suite tightening compared to DTLS 1.2. Tier 1.
- RFC 9605 — Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media, Omara, Uberti et al., August 2024. Standards-track. End-to-end encryption framework for media frames through an SFU; cited in the E2EE section. Tier 1.
- RFC 8844 — Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP), Thomson, Holmberg, January 2021. Standards-track. Documents the unknown-key-share attack class against DTLS-SRTP and the
tls-idmitigation. Tier 1. - W3C WebRTC Identity Specification, W3C, 2023 (Candidate Recommendation Snapshot). Defines
RTCPeerConnection.setIdentityProvider()and the IdP integration model discussed in the Identity section. Tier 1. - WebRTC Source:
transport-wide-cc-02and SRTP profile documentation, Google. Reference implementation documentation for the cipher-suite negotiation and SRTP profile selection in libwebrtc. Tier 2. - draft-ietf-mmusic-mdns-ice-candidates-02, Uberti, Shieh. IETF draft for mDNS host-candidate obfuscation, used by Chrome since 2019 to hide local IPs in WebRTC SDP. Cited for the privacy-leak discussion. Tier 1 (draft — subject to revision before RFC publication).
- The WebRTC Security Architecture (rtcweb-wg), IETF rtcweb working group, living document. The pre-RFC editor's copy of the security architecture document, used by the WG for ongoing edits — useful for understanding pre-RFC 8827 drafts and rationale. Tier 2.
