Robustness principle: Difference between revisions

Revision as of 13:38, 9 August 2018

Revision as of 09:22, 13 September 2018

Line 17:

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. |authorlink=Marshall Rose |year=2001 |month=November |publisher=[[Internet Engineering Task Force|IETF]] |accessdate=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".

In ana 2017 [[Internet-Draft of 2017]], 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 Postel's Maxim |last=Thomson |first=Martin |year=2017 |month=October |url=https://tools.ietf.org/html/draft-thomson-postel-was-wrong-02 |publisher=[[Internet Engineering Task Force|IETF]] |accessdate=January 15, 2018}}</ref>

In a published paper to the annual Privacy Enhancing Technologies Symposium (PETS)<ref>https://petsymposium.org</ref>, Florentin Rochet and Olivier Pereira show how to exploit Postel's robustness principle inside the Tor routing protocol to compromise the anonymity of onion services and Tor clients.<ref>https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf</ref>