Robustness principle - Wikipedia  🔗 **Source:** [Robustness principle - Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle) > [!note]+ Document Notes > --- > tags: [postels-law, robustness-principle, protocol-design, interop, rfc, network-security, tor, standards, bug-for-bug-compatibility, specification] > title: Robustness principle (Postel's law) > author: Wikipedia contributors > source: "Wikipedia" > reference: https://en.wikipedia.org/wiki/Robustness_principle > date created: 2026-09-04 11:35 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > [!warning] Provenance and why this was read > > **Encyclopedic tertiary source**, collectively authored, no byline. Treat it as a map of the literature, not as an authority; every substantive claim here is attributed to a numbered primary source (RFC 761, RFC 1122, RFC 3117, Thomson's drafts, Rochet & Pereira) and those are what to cite. > > **Read as the third document in a cluster.** Winer's [[3. Resources/Readwise/Articles/Rules for Standards-Makers|Rules for standards-makers]] invokes this principle explicitly — and cites exactly half of it. This page is where the other half's twenty-five-year argument lives, which makes the pairing more informative than either document alone. > > **Short article, dense citations.** ~4,200 characters of prose over six numbered references spanning 1980–2019. > # 🏷️ Title: Robustness principle (Postel's law) > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#️-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > - [🧱 Refactor Appendix](#-refactor-appendix) > - [🧰 Template Library](#-template-library) > ### 🔗 References (in-page) > - Source: https://en.wikipedia.org/wiki/Robustness_principle > - RFC 761 — Postel, ed., *Transmission Control Protocol*, Jan 1980 (doi:10.17487/RFC0761) > - RFC 1122 — Braden, ed., *Requirements for Internet Hosts: Communication Layers*, Oct 1989 (doi:10.17487/RFC1122) > - RFC 3117 — Rose, *On the Design of Application Protocols*, Nov 2001 (doi:10.17487/RFC3117) > - Thomson, Martin — *The Harmful Consequences of the Robustness Principle*, IETF, May 2019 > - Rochet & Pereira — "Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols," PETS 2018 > - Wilde, Erik — *Wilde's WWW: Technical Foundations of the World Wide Web*, Springer-Verlag, 2012 [1999], p. 26 > ## 📝 Summary > **The principle.** "Be conservative in what you do, be liberal in what you accept from others" — Jon Postel, in the January 1980 TCP specification (RFC 761). Commonly reworded as "be conservative in what you send, be liberal in what you accept." Programmers know a typed restatement of it: be contravariant in the input type and covariant in the output type. > **What it asks for.** Senders should conform completely to the specification; receivers should accept non-conformant input as long as the meaning is clear. RFC 1122 (1989) extended it with a security posture — assume the network is full of malevolent entities sending packets designed for the worst possible effect — and with forward-compatibility guidance: accept unknown codes in existing fields, avoid sending legal-but-obscure features that expose receiver deficiencies, and cooperate to limit the disruption misbehaving hosts can cause. > **The case against, which is the article's real content.** Three escalating critiques over twenty years. Rose (RFC 3117, 2001): a defective implementation survives undetected among tolerant peers until it meets a strict one years later, at which point diagnosis is hard and the fix is expensive — so build explicit consistency checks even at implementation cost. Thomson (2015–2018 drafts, published 2019): the principle actively *reduces* robustness, because a flaw becomes entrenched as a de facto standard that every implementation must then replicate to interoperate — "bug for bug compatible." Rochet & Pereira (PETS 2018): a working exploit, using Postel-style tolerance inside Tor's routing protocol to compromise the anonymity of onion services and clients. > **Stakeholders.** Protocol designers and implementors; security researchers; anyone maintaining a parser at an internet trust boundary. > **Bottom line.** The principle's two halves have had opposite fates. "Be conservative in what you send" is uncontroversial and remains good advice. "Be liberal in what you accept" has accumulated a substantial, specific, and partly empirical case against it, culminating in a demonstrated attack. Citing "Postel's law" approvingly without saying which half is doing the work is now an imprecision worth noticing — including in Winer's document, though he is unusually careful and cites only the send-half by name. > ## 📖 Main Content > **The asymmetry is the design, not an accident.** Postel's formulation deliberately assigns different obligations to the two ends of a connection: strictness where you control the output, tolerance where you don't control the input. In 1980, with a small number of independently written implementations trying to bootstrap a working network, that asymmetry is what let deployment proceed without global coordination. The principle solved a real problem, and reading the criticism without that context makes it look naive rather than situated. > **RFC 1122 quietly changed the principle's character.** Braden's 1989 expansion pairs Postel's tolerance with the instruction to assume the network is filled with malevolent entities. Those two ideas are in obvious tension — be generous with input, and assume input is hostile — and the resolution offered is a narrower reading: tolerate *unknown but well-formed* extensions, do not tolerate *malformed* input. Much of the later criticism can be read as arguing that this distinction, though correct, is not what implementors actually did. > **Rose's critique is about time, not correctness.** RFC 3117's insight is that liberal acceptance doesn't prevent failures, it *defers* them — and defers them to the worst possible moment, when the defective implementation is already deployed, its author has moved on, and the failure surfaces as an interop bug between two parties who are both behaving reasonably. His prescription — explicit consistency checks even at implementation cost — is the direct ancestor of "ship a validator," and it is worth noticing that Rose was willing to pay runtime overhead for early failure. > **Thomson's critique is the strongest and is structural.** The claim is not that tolerance causes bugs but that it causes bugs to become *load-bearing*. Once a flawed implementation is widely deployed and tolerated, every new implementation must reproduce the flaw to interoperate, so the aberrant behavior is promoted from defect to requirement. "Bug for bug compatible" names an equilibrium nobody chose and nobody can unilaterally leave. The article also records his observation that this is reinforced by a natural reluctance to trigger fatal errors — the humane instinct and the correct instinct diverge. > **Rochet & Pereira convert theory into an exploit.** The 2018 PETS paper is the article's most consequential citation because it is the only one that fires the claim rather than arguing it: Postel-style flexibility inside onion routing was used to confirm traffic and compromise anonymity for both onion services and clients. That moves "liberal acceptance is risky" from a design opinion to a demonstrated attack surface in a system whose entire purpose is resisting exactly that class of adversary. > **The "See also" list is a genuine argument in miniature.** Unix philosophy, static discipline, and the open–closed principle are In [computing](https://en.wikipedia.org/wiki/Computing), the **robustness principle** is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as **Postel's law**, after [Jon Postel](https://en.wikipedia.org/wiki/Jon_Postel), who used the wording in an early specification of [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol).[[1]](https://en.wikipedia.org/wiki/Robustness_principle#cite_note-1) In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear. Among programmers, to produce [compatible functions](https://en.wikipedia.org/wiki/Liskov_substitution_principle), the principle is also known in the form [be contravariant in the input type and covariant in the output type](https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)). #### Interpretation RFC 1122 (1989) expanded on Postel's principle by recommending that programmers "assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect".[[2]](https://en.wikipedia.org/wiki/Robustness_principle#cite_note-2) Protocols should allow for the addition of new codes for existing fields in future versions of protocols by accepting messages with unknown codes (possibly logging them). Programmers should avoid sending messages with "legal but obscure protocol features" that might expose deficiencies in receivers, and design their code "not just to survive other misbehaving hosts, but also to cooperate to limit the amount of disruption such hosts can cause to the shared communication facility".[[3]](https://en.wikipedia.org/wiki/Robustness_principle#cite_note-Wilde2012-3) #### Criticism In 2001, [Marshall Rose](https://en.wikipedia.org/wiki/Marshall_Rose) characterized several deployment problems when applying Postel's principle in the design of a new application protocol.[[4]](https://en.wikipedia.org/wiki/Robustness_principle#cite_note-4) For example, a defective implementation that sends non-conforming messages might be used only with implementations that tolerate those deviations from the specification until, possibly several years later, it is connected with a less tolerant application that rejects its messages. In such a situation, identifying the problem is often difficult, and deploying a solution can be costly. Rose therefore recommended "explicit consistency checks in a protocol ... even if they impose implementation overhead". From 2015 to 2018, in a series of [Internet-Drafts](https://en.wikipedia.org/wiki/Internet-Draft), Martin Thomson argues that Postel's robustness principle actually leads to a *lack* of robustness, including security:[[5]](https://en.wikipedia.org/wiki/Robustness_principle#cite_note-5) > A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. This is both a consequence of applying the robustness principle, and a product of a natural reluctance to avoid fatal error conditions. Ensuring interoperability in this environment is often referred to as aiming to be "bug for bug compatible". > > In 2018, a paper on [privacy-enhancing technologies](https://en.wikipedia.org/wiki/Privacy-enhancing_technologies) by Florentin Rochet and Olivier Pereira showed how to exploit Postel's robustness principle inside the [Tor](https://en.wikipedia.org/wiki/Tor_(anonymity_network)) [routing protocol](https://en.wikipedia.org/wiki/Onion_routing) to compromise the anonymity of onion services and Tor clients.[[6]](https://en.wikipedia.org/wiki/Robustness_principle#cite_note-6) #### See also * [Unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy) * [Static discipline](https://en.wikipedia.org/wiki/Static_discipline) * [Open–closed principle](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle) #### References 1. **[^](https://en.wikipedia.org/wiki/Robustness_principle#cite_ref-1)** [Postel, Jon](https://en.wikipedia.org/wiki/Jon_Postel), ed. (January 1980). [*Transmission Control Protocol*](https://datatracker.ietf.org/doc/html/rfc761). [IETF](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force). [doi](https://en.wikipedia.org/wiki/Doi_(identifier)):[10.17487/RFC0761](https://doi.org/10.17487%2FRFC0761). [RFC](https://en.wikipedia.org/wiki/RFC_(identifier)) [761](https://datatracker.ietf.org/doc/html/rfc761). Retrieved June 9, 2014. 2. **[^](https://en.wikipedia.org/wiki/Robustness_principle#cite_ref-2)** [Braden, R.](https://en.wikipedia.org/wiki/Bob_Braden), ed. (October 1989). [*Requirements for Internet Hosts: Communication Layers*](https://datatracker.ietf.org/doc/html/rfc1122). [IETF](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force). [doi](https://en.wikipedia.org/wiki/Doi_(identifier)):[10.17487/RFC1122](https://doi.org/10.17487%2FRFC1122). [RFC](https://en.wikipedia.org/wiki/RFC_(identifier)) [1122](https://datatracker.ietf.org/doc/html/rfc1122). Retrieved June 9, 2014. 3. **[^](https://en.wikipedia.org/wiki/Robustness_principle#cite_ref-Wilde2012_3-0)** Wilde, Erik (2012) [1999]. [*Wilde's WWW: Technical Foundations of the World Wide Web*](https://archive.org/details/springer_10.1007-978-3-642-95855-7). Springer‑Verlag. p. [26](https://archive.org/details/springer_10.1007-978-3-642-95855-7/page/n48). [doi](https://en.wikipedia.org/wiki/Doi_(identifier)):[10.1007/978-3-642-95855-7](https://doi.org/10.1007%2F978-3-642-95855-7). [ISBN](https://en.wikipedia.org/wiki/ISBN_(identifier)) [978-3-642-95855-7](https://en.wikipedia.org/wiki/Special:BookSources/978-3-642-95855-7). 4. **[^](https://en.wikipedia.org/wiki/Robustness_principle#cite_ref-4)** [Rose, M.](https://en.wikipedia.org/wiki/Marshall_Rose) (November 2001). [*On the Design of Application Protocols*](https://datatracker.ietf.org/doc/html/rfc3117). [IETF](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force). [doi](https://en.wikipedia.org/wiki/Doi_(identifier)):[10.17487/RFC3117](https://doi.org/10.17487%2FRFC3117). [RFC](https://en.wikipedia.org/wiki/RFC_(identifier)) [3117](https://datatracker.ietf.org/doc/html/rfc3117). Retrieved June 9, 2014. 5. **[^](https://en.wikipedia.org/wiki/Robustness_principle#cite_ref-5)** Thomson, Martin (May 2019). [*The Harmful Consequences of the Robustness Principle*](https://tools.ietf.org/html/draft-iab-protocol-maintenance). [IETF](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force). Retrieved October 4, 2019. 6. **[^](https://en.wikipedia.org/wiki/Robustness_principle#cite_ref-6)** Rochet, Florentin; Pereira, Olivier (2018). ["Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols"](https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf) (PDF). *Proceedings of the Privacy Enhancing Technologies Symposium*. De Gruyter Open (2): 27–46. [ISSN](https://en.wikipedia.org/wiki/ISSN_(identifier)) [2299-0984](https://www.worldcat.org/issn/2299-0984). #### External links * [History of the (Internet) Robustness Principle](https://ironick.typepad.com/ironick/2005/05/my_history_of_t.html) (Nick Gall, May 2005) * [Internet Protocol](https://www.postel.org/ien/txt/ien111.txt), page 22; J. Postel, [IEN](https://en.wikipedia.org/wiki/Internet_Experiment_Note) 111, August 1979., Robustness principle - Wikipedia, Wikipedia contributors, 01m1pmwhxzzntqfafmqz9fxwsq.