Robustness principle: Difference between revisions

Revision as of 20:53, 2 April 2024

Revision as of 19:07, 21 June 2024

Line 13:

In 2001, [[Marshall Rose]] characterized several deployment problems when applying Postel's principle in the design of a new application protocol.<ref>{{cite IETF |title=On the Design of Application Protocols |rfc=3117 |last=Rose |first=M. |author-link=Marshall Rose |date=November 2001 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=June 9, 2014}}</ref> 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&nbsp;... even if they impose implementation overhead".

From 2015 to 2018, in a series of [[Internet Draft]]s, Martin Thomson argues that Postel's robustness principle actually leads to a ''lack'' of robustness, including security:<ref>{{cite IETF |title=The Harmful Consequences of the Robustness Principle |last=Thomson |first=Martin |date=May 2019 |url=https://tools.ietf.org/html/draft-iab-protocol-maintenance |publisher=[[Internet Engineering Task Force|IETF]] |access-date=October 4, 2019}}</ref>{{Quote|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 compatibility|bug for bug compatible]]".}}

In 2018, a paper on [[privacy-enhancing technologies]] by Florentin Rochet and Olivier Pereira showed how to exploit Postel's robustness principle inside the [[Tor (anonymity network)|Tor]] [[Onion routing|routing protocol]] to compromise the anonymity of onion services and Tor clients.<ref>{{cite journal | url = https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf | title = Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols | first1 = Florentin | last1 = Rochet | first2= Olivier | last2 = Pereira | journal = Proceedings of the Privacy Enhancing Technologies Symposium | issn = 2299-0984 | publisher = De Gruyter Open | year = 2018 | volume = 2018 | issue = 2 | pages = 27–46 | doi = 10.1515/popets-2018-0011 }}</ref>

FromIn 2015 to 20182023, inMartin aThomson seriesand ofDavid [[Internet Draft]]s, Martin ThomsonSchinazi arguesargued that Postel's robustness principle actually leads to a ''lack'' of robustness, including security:<ref>{{cite IETFRef RFC|title=The Harmful Consequences of the Robustness Principle |last=Thomson |first=Martin |date=May 2019 |url=https://tools.ietf.org/html/draft-iab-protocol-maintenance |publisher=[[Internet Engineering Task Force|IETF]] |access-date=October 4, 20199413}}</ref>{{Quote|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 applyingtolerating the robustness principle,unexpected 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 compatibility|bug -for -bug compatible]]".}}

== See also ==