On Tue, Oct 16, 2018 at 02:01:48PM -0400, Daniel Corbe wrote:

The one thing I remember about Postel, other than the fact that he had his fingers in a lot of DNS pies, is be liberal about what you accept, be conservative about what you send. It’s a notion that creates undo burden on the implementor, because it places the expectation on the that you need to account for every conceivable ambiguous corner case and that’s not always the best approach when implementing a standard; and it mostly arises from the lack of adherence to the second part of that statement.

I think that his aphorism is simply a recognition that NO standard can cover all cases that might arise when dealing with complex matters, no matter how much thought went into it. People are fallible, and the standards they write are inevitably flawed in some way, so a realistic implementor has to allow some slack or be continually engaged in finger-pointing when something doesn't work. - Brian

On Oct 16, 2018, at 4:57 PM, Wayne Bouchard <web@typo.org> wrote:

Well, simply put, the idea is that you should be able to compensate for a certain amount of deviation from accepted usage as long as its still within what the protocol allows (or can be read to allow) but that you yourself should act with a fairly strict interpretation. In others, don't be the one *causing* the problems...

Indeed. To give a TCP example, the opening exchange is theoretically SYN, SYN ACK, ACK. A common case is that it is SYN, SYN ACK, data, either because the ACK got lost, or because someone cut a corner. The issue is to note that the SYN might have been duplicated in flight, and the receiver might therefore have the appearance of two sessions. Which one? The ACK (or data segment) - any segment within the sessions - clarifies that. So, if there is a minor protocol violation but the intent it clear, follow the intent. The alternative version of the Robustness Principle: "S**t happens; deal with it." Says someone who has implemented such things... -------------------------------------------------------------------------------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu

I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others. Mike On 10/16/2018 07:18 PM, bzs@theworld.com wrote:

What it's trying to say is that you have control over your own code but not others', in general.

So make your own code (etc) robust and forgiving since you can't edit others' code to conform to your own understanding of what they should be sending you.

I suppose that pre-dates github but nonetheless much of the code which generates bits flung at you is proprietary and otherwise out of your control but what you can control is your code's reaction to it.

And of course the bits you generate which should try to make conservative assumptions about what they might accept and interpret as you expect.

For example just because they sent you a seemingly malformed HTTP request, and given that 4xx is for error codes, doesn't mean you should return "420 You must be high!" and expect to be understood.

On 10/16/2018 08:20 PM, bzs@theworld.com wrote:

On October 16, 2018 at 19:35 mike@mtcc.com (Michael Thomas) wrote:

...

I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.

Security fits into all this, being liberal in what you accept doesn't mean you do whatever they ask.

Quite the contrary it means make sure your code doesn't roll over dead or misbehaving just because you received an unexpected input.

That's not the same thing. That's never acceptable. Trying to educe what a sender really meant is a good way to create exploitable spaghetti though. But don't take my word for it, reach out to people who pay more attention to such things than me. Mike

On 10/16/2018 08:36 PM, Scott Brim wrote:

On Tue, Oct 16, 2018, 22:37 Michael Thomas <mike@mtcc.com <mailto:mike@mtcc.com>> wrote:

I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.

Mike

I saw just a small swing of the pendulum toward the center, a nuanced meaning for "liberal". The adage wasn't tossed out. Operationally it can't be.

All of the security types were pretty unanimous when this came up during all of the dkim stuff i worked on. I was a fan, and I got schooled. Mike

I'm probably going to regret posting this but I think most of this dispute regarding Jon Postel's advice revolves around how the words "liberal" and "conservative" have changed over 20 years. Liberal used to mean adaptable, open-minded, and conservative used to mean cautious and hewing close to the rules (and I mean none of that disparagingly.) <IGNORE> I won't begin to characterize how these words have changed but, um, ach, phffft, AGHHH!...they didn't mean calling your personal prostitute a "horseface" or arguing that point via the public internet. </IGNORE> -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On 2018-10-17 02:35, Michael Thomas wrote:

I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.

Postel's maxim also allowed extensibility.  If our network code rejects (or crashes) on things we don't currently understand and use, it ensures that they can't be used by apps that come along later either.  The attitude of rejecting everything in the name of security is what has forced app developers to tunnel APIs and everything else inside HTTP/DNS.

Mike

On 10/16/2018 07:18 PM, bzs@theworld.com wrote:

...

What it's trying to say is that you have control over your own code but not others', in general.

So make your own code (etc) robust and forgiving since you can't edit others' code to conform to your own understanding of what they should be sending you.

I suppose that pre-dates github but nonetheless much of the code which generates bits flung at you is proprietary and otherwise out of your control but what you can control is your code's reaction to it.

And of course the bits you generate which should try to make conservative assumptions about what they might accept and interpret as you expect.

For example just because they sent you a seemingly malformed HTTP request, and given that 4xx is for error codes, doesn't mean you should return "420 You must be high!" and expect to be understood.

On 10/17/2018 12:43 PM, Florian Weimer wrote:

* Laszlo Hanyecz:

...

...

I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others. Postel's maxim also allowed extensibility.  If our network code rejects (or crashes) on things we don't currently understand and use, it ensures

On 2018-10-17 02:35, Michael Thomas wrote: that they can't be used by apps that come along later either.  The attitude of rejecting everything in the name of security is what has forced app developers to tunnel APIs and everything else inside HTTP/DNS.

Let's be clear: crashing is a software bug. It has nothing to do with Postel. On the extensibility part, that is for the protocol itself to define, and it should be explicit. If the protocol says to reject, then you must reject. I'm not sure if extensibility one of the global protocol check offs, but it certainly should be part of any stander.

To be fair, a lot of these components that make extending protocols hard are both receivers and senders. If they are asked to forward garbage, then something has to give.

Yes, the protocol should tell you what to do. If it doesn't, its deficient. Mike