On 18.6.2017 20:09, Joe Touch wrote:
> FWIW:
>
> On 6/17/2017 7:18 AM, Petr Špaček wrote:
>>> What the specification leaves open, implementations should respect and
>>> honor as allowed.
>> This is exactly the point where our opinions differ.
>> My point of view is that specification should clearly define extension
>> points and implementations should:
>> a) Use Postel's principle within defined 'extension' points.
>> b) Treat any deviation from documented protocol (including non-defined
>> aspects of protocol outside of extension points) as an error.
> You're asking for 10,000 page specifications and 10MB protocol
We do not understand each other here. Let me explain what I meant in
different terms:
For purpose of this example, please imagine that protocol description
(and sometimes also implementation) is a finite state automata.
Right now, if a edge in the automata is not defined as result of
protocol under-specification, it is up to implementation to decide what
to do, i.e. implementation has to guess sender's intent.
This "guess" part is where I see problems because various
implementations naturally differ in their "guesses" and this is causing
problems later on.
I argue that default action triggered by "imagined missing edge" in our
hypothetical protocol automata should be "report protocol specific error
to sender".
This could be done by adding ~ two paragraphs to protocol specification.
One defining how error message looks like (this is already present in
e.g. DNS spec as FORMERR) and second explaining that non-defined inputs
should be treated as errors. Implementations always has to have some
code to handle erroneous inputs (ala switch { default: } ) as well.
I cannot see the 10 MB of code here.
> implementations that are vulnerable to attack.
Could you elaborate on that? I still do not see how early error
reporting invites DoS. In fact I believe that is is improving overall
situation because smaller set of accepted inputs makes it easier to
handle corner cases and to avoid crash bugs.
>> Nice set of reasons for being strict when receiving messages is
>> described in the following article:
>>
>> "A Patch for Postel's Robustness Principle",
>> Len Sassaman, Meredith L. Patterson, Sergey Bratus,
>> 2012 IEEE S&P Journal,
>> http://langsec.org/papers/postel-patch.pdf
> I would encourage them to read Shannon/Weaver as well.
(copied from Message-ID: <3a0a263f-f3b4-1931-3c49-4fa1526658e5@xxxxxxx>)
> IMO, it's somewhat an extension of Shannon's recognition that
> communication is about symbol agreement, not semantics or intent.
We have tried to be liberal in DNS protocol in last 25 years. It
resulted in humongous mess which in the end forces sender to do multiple
guesses until he finds meaning of particular "symbol" for that
particular "receiver". This necessitates means for caching
"receiver-symbol meaning" which brings its own problems. I'm sure that
Mark Andrews can tell you wild stories about EDNS version negotiation.
In other words, we had 25+ years to try this liberal approach in DNS and
now it is time to learn from that experience.
Thank you for your time, I really appreciate it.
Petr Špaček @ CZ.NIC