5 ms·

Careful with Postel's Law: it brought us a lot the mess we have with web standards. Quoting wikipedia https://en.wikipedia.org/wiki/Robustness_principle https:

by VMG 11y ago

Careful with Postel's Law: it brought us a lot the mess we have with web standards. Quoting wikipedia https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle: > In RFC 3117, Marshall Rose characterized several deployment problems when applying Postel's principle in the design of a new application protocol.[3] 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".

bluejekyll 11y ago
Yeah. I agree that this is a slippery slope. SMTP followed this, and there were a lot of whacky things, then qmail came and rejected the bad implementations. Perhaps it's better to use this law for UI, where being liberal with accepting things by trimming white space is better than rejecting, which would confuse an end user.
- edejong 11y ago
  Perhaps, but we introduce a new implicit specification by doing this, possibly closing the door for situations where white-space is relevant. The common appearance of the ignorant user seems to stem from him generalizing patterns as a holdover from one UI to another. Perhaps we should better study these patterns and steer the user to a consistent path. But instead, it seems we're trying to out-smart him time and time again, creating a jungle of user interactions which merely belittle and confuse.
kbenson 11y ago
That may be true, but it's only a problem if you believe we are capable of designing sane, useful standards initially. Postel's law allows a limited form of evolution for standards. Sometimes that allows for useful extensions to be adopted into later revisions, other times it can run rampant and create monstrous mutations (which might still be accepted. I'm looking at you, IMAP).
edejong 11y ago
How I wish more engineers would take this precaution, as it is arguable the law caused harm over good, well intended as it might be. Engineering with unspecified bounds often needlessly introduces complexity and cost.
mjevans 11y ago
This is better observed as having a separate standards compliance check and 'reference implementation'. The standards compliance check evaluates if a given program or module complies with the written standard. The reference implementation is free to be more fault tolerant or otherwise assume that invalid input is allowed to produce undefined results (as long as they are not clearly the wrong behavior).
pdkl95 11y ago
Being liberal in what you accept is fine, iff strictly define the variations in the grammar. Meredith and Sergey's outstanding talk about properly parsing all input discusses this update to how Postel's Law should be interpreted. https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit
- quanticle 11y ago
  I would argue that if you're strictly defining the accepted variations in the grammar, then all you've done is define a new grammar that you're conservatively adhering to. And that's fine! There's no rule that says that standards cannot evolve to match new use cases. However, I would argue that having a strictly defined (yet evolving) standard is much different than the common interpretation of Postel's Law, which is that undefined behavior should "do the right thing", with the specific interpretation of "the right thing" being left to the implementers. Predictably, different implementers interpret that in different ways, which leads to security holes. But if the specification defines what the right thing to do is, then the behavior is no longer undefined, and therefore Postel's Law no longer applies.
- VMG 11y ago
  Thanks! The link is missing a trailing `y`.
quanticle 11y ago
The other big problem with Postel's law is that it makes enforcing security guarantees a nightmare. When each component in a system is "liberal in what it accepts", it's very easy to fall into a trap where component A thinks that component B is performing the security checks and component B thinks that component A is performing the check and as a result the security check is either never performed or trivially sidestepped. A good example of this was the vulnerability with null characters in SSL certificates [0]. In that vulnerability, both the browser and the certification authority interpreted the domain with the null character as "liberally" as possible, but their differing interpretations of what constituted "forgiving" made it trivial to spoof SSL certificates merely by including a null character in your domain. Another example is with guarding against XSS vulnerabilities. Browsers try to be liberal in what constitutes valid Javascript, and will attempt to execute even the most malformed scripts they encounter. This makes it unnecessarily difficult to shield against XSS - one must block a whole range of vectors, rather than just script tags. [0]: http://trevorjim.com/postels-law-and-network-security/ http://trevorjim.com/postels-law-and-network-security/
Gibbon1 11y ago
I think it's okay when dealing with input from hairless monkeys. That people just aren't particularly consistent is part of the problem domain. Not so okay when dealing with input created by programs. And as you said totally not okay when dealing with protocols, encryption, and authentication. See padding attacks.

by VMG 11y ago

bluejekyll 11y ago

Yeah. I agree that this is a slippery slope. SMTP followed this, and there were a lot of whacky things, then qmail came and rejected the bad implementations. Perhaps it's better to use this law for UI, where being liberal with accepting things by trimming white space is better than rejecting, which would confuse an end user.

edejong 11y ago
Perhaps, but we introduce a new implicit specification by doing this, possibly closing the door for situations where white-space is relevant. The common appearance of the ignorant user seems to stem from him generalizing patterns as a holdover from one UI to another. Perhaps we should better study these patterns and steer the user to a consistent path. But instead, it seems we're trying to out-smart him time and time again, creating a jungle of user interactions which merely belittle and confuse.

kbenson 11y ago

That may be true, but it's only a problem if you believe we are capable of designing sane, useful standards initially. Postel's law allows a limited form of evolution for standards. Sometimes that allows for useful extensions to be adopted into later revisions, other times it can run rampant and create monstrous mutations (which might still be accepted. I'm looking at you, IMAP).

edejong 11y ago

How I wish more engineers would take this precaution, as it is arguable the law caused harm over good, well intended as it might be. Engineering with unspecified bounds often needlessly introduces complexity and cost.

mjevans 11y ago

This is better observed as having a separate standards compliance check and 'reference implementation'. The standards compliance check evaluates if a given program or module complies with the written standard. The reference implementation is free to be more fault tolerant or otherwise assume that invalid input is allowed to produce undefined results (as long as they are not clearly the wrong behavior).

pdkl95 11y ago

Being liberal in what you accept is fine, iff strictly define the variations in the grammar. Meredith and Sergey's outstanding talk about properly parsing all input discusses this update to how Postel's Law should be interpreted. https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit

quanticle 11y ago
I would argue that if you're strictly defining the accepted variations in the grammar, then all you've done is define a new grammar that you're conservatively adhering to. And that's fine! There's no rule that says that standards cannot evolve to match new use cases. However, I would argue that having a strictly defined (yet evolving) standard is much different than the common interpretation of Postel's Law, which is that undefined behavior should "do the right thing", with the specific interpretation of "the right thing" being left to the implementers. Predictably, different implementers interpret that in different ways, which leads to security holes. But if the specification defines what the right thing to do is, then the behavior is no longer undefined, and therefore Postel's Law no longer applies.
VMG 11y ago
Thanks! The link is missing a trailing `y`.

quanticle 11y ago

The other big problem with Postel's law is that it makes enforcing security guarantees a nightmare. When each component in a system is "liberal in what it accepts", it's very easy to fall into a trap where component A thinks that component B is performing the security checks and component B thinks that component A is performing the check and as a result the security check is either never performed or trivially sidestepped. A good example of this was the vulnerability with null characters in SSL certificates [0]. In that vulnerability, both the browser and the certification authority interpreted the domain with the null character as "liberally" as possible, but their differing interpretations of what constituted "forgiving" made it trivial to spoof SSL certificates merely by including a null character in your domain. Another example is with guarding against XSS vulnerabilities. Browsers try to be liberal in what constitutes valid Javascript, and will attempt to execute even the most malformed scripts they encounter. This makes it unnecessarily difficult to shield against XSS - one must block a whole range of vectors, rather than just script tags. [0]: http://trevorjim.com/postels-law-and-network-security/ http://trevorjim.com/postels-law-and-network-security/

Gibbon1 11y ago

I think it's okay when dealing with input from hairless monkeys. That people just aren't particularly consistent is part of the problem domain. Not so okay when dealing with input created by programs. And as you said totally not okay when dealing with protocols, encryption, and authentication. See padding attacks.