Summary

  • RFC 6973 gives protocol authors a questionnaire for identifying data, observers, linkability, retention, user control, security and design trade-offs; it is a basis for argument, not a universal score.
  • Privacy properties change when a protocol is combined with other systems, identifiers and outside data, then implemented with particular interfaces, defaults, logs and operating practices.
  • A credible privacy claim therefore needs a versioned threat model and deployment evidence alongside the review: who can observe what, which joins are possible, how long data survives, which defaults actually run and who owns residual risk.

A completed form with no verdict box

RFC 6973 was published in July 2013 as an Informational product of the Internet Architecture Board. Cooper is its first-listed author, joined by Hannes Tschofenig, Bernard Aboba, Jon Peterson, John Morris, Marit Hansen and Rhys Smith. That collective authorship matters. The document is institutional guidance preserved for the record, not a private theory and not an Internet Standards Track specification.

Its most useful restraint appears before the questionnaire. Privacy is understood differently across people, disciplines and jurisdictions. The guidance therefore aims at concrete engineering choices without pretending to settle every legal or social definition. Even the location of a privacy discussion depends on the document: it may have its own section, sit inside security considerations, run throughout the specification or be unnecessary for a narrowly technical codec.

That makes the framework harder to market and more useful to govern. A checklist sold as certification wants one terminal state. RFC 6973 instead asks authors to expose a chain of judgment. A reviewer can challenge missing actors, unjustified persistence or a weak default. The completed answers become a basis for discussion about adequacy. They do not convert a design into a timeless property called “private”.

The protocol boundary moves after publication

Internet protocols are designed for reuse. An element that looks harmless in isolation can become identifying when combined with another protocol, an account, a location history or an operator's logs. Architectures also emerge after implementations exist. The people who deploy a protocol years later may not be the people who chose its original fields.

RFC 6973 therefore locates privacy in a larger system: protocol composition, product design, implementation, interface, default settings, security process and operations. A specification can constrain syntax and recommend behavior. It rarely controls how long an intermediary retains records, whether analytics joins two identifiers, whether a user can understand a preference, or whether an operator silently selects a less protective mode.

This is not an excuse to write nothing. It is a demand to declare the analysis boundary. Authors should examine expected interactions beyond the protocol while admitting that they cannot imagine every future use. A privacy review is reliable when it says what it covered, which assumptions it made and which decisions remain with implementers and operators.

One word cannot hold all privacy harm

The RFC refuses to treat privacy as a synonym for confidentiality. It describes possible harm to finances, reputation, solitude, autonomy and physical safety. It then separates surveillance, compromise of stored data, misattribution, correlation, identification, secondary use, disclosure, exclusion and intrusion.

Those distinctions alter engineering decisions. Correlation can join activities before an observer knows a civil identity. Identification can arise later from that joined history. A pseudonym may hide a name while remaining stable enough to track. Encryption may protect content in transit while packet timing, size, endpoints or a long-lived token still reveal a pattern. Consent may change expectations, but it does not delete copied data or make an unexpected secondary use technically impossible.

The observer is part of the property. An anonymity set exists relative to what a particular observer knows, and its membership can shrink over time. “Anonymous” without an observer, auxiliary-data assumption and time window is therefore not a complete claim. The same is true of “unlinkable”, “minimal” and “private”.

Three mitigation families, three different control surfaces

RFC 6973 groups mitigation around data minimization, user participation and security. Data minimization asks teams to limit collection, use, disclosure, retention, identifiability, sensitivity and access to what a task needs. Protocol authors can remove a field, shorten an identifier's life or allow replacement. They may only be able to recommend, rather than enforce, how an operator uses or retains the resulting records.

User participation asks who can control disclosure to recipients and intermediaries, express preferences and understand the choice. Some of that machinery belongs in a protocol; much of it lives in a product interface, contract or operating procedure. A wire format that can carry a preference does not prove that the default exposes it clearly or that every recipient honors it.

Security mitigates eavesdropping, stored-data compromise, intrusion and misattribution, among other threats. Yet a secure channel is not a full privacy design. The operator at either end may legitimately see plaintext and still over-collect it. Strong authentication may prevent impersonation while making activity easier to join. The question is not whether security is present, but which threat it changes and which data relationships remain.

The questions are a review record

Section 7 asks authors to inventory identifiers and other exposed information, then assign visibility to recipients, intermediaries and enablers. It asks whether ordering or occurrence of elements permits fingerprinting; how long identifiers persist; whether interactions can be correlated with outside information; and why any recipient must retain the data.

The questionnaire then follows control into user participation and security. Can people share different information with different recipients? Can they limit intermediary exposure? Are preferences transmitted, and are external controls assumed? What leaks through traffic analysis? What protects stored data? How are intrusion and misattribution handled?

The final questions prevent a team from hiding policy inside defaults. If a less protective mode ships by default, the reason should be stated. Trade-offs among privacy, usability, efficiency and implementability should be explicit. This does not select the correct answer for every protocol. It creates a reviewable record of who accepted which compromise under which assumptions.

Later surveillance work made context more, not less, important

RFC 7258 later classified pervasive monitoring as a technical attack that protocol designers should mitigate where possible. Its definition of mitigation is deliberately modest: make attack more expensive, more visible or less effective, rather than promise total prevention. It also notes that some monitoring is necessary for management, abuse control or transparency and that the IETF does not control implementation, deployment, every layer or non-technical responses.

RFC 7624 widened the model further. A capable observer can collect content and metadata across many protocols, sessions and storage systems, then correlate the pieces. The privacy claim for one well-reviewed protocol can fail at its joins. That is why early architectural review matters and why the review must travel with deployment evidence instead of ending at RFC publication.

The institutional value of RFC 6973 is not a stamp. It is a common language for refusing an unsupported stamp. A team can show its threat model, data-flow inventory, observer matrix, default decision, retention bounds and unresolved risks. Auditors can then test the implementation and operation that actually exist.

Sources