John Day wrote:
It would be interesting to see you apply that.
This is what I have been talking about. The human mind's ability to
believe that the whole world sees everything the same way they do.
It really is quite amazing.
These so-called gaps often arise because they were unstated
assumptions or things that the author believed were patently obvious
and didn't need to be stated. Actually didn't know needed to be
stated. From his point of view, no one would do it differently.
Nothing had been left out and he didn't make the "mistake." What
the other guys did was a bug.
There is a much greater range of interpreting these things than it
appears that you imagine.
With "bug", I mean behaviour that is non-compliant with the spec,
where the difference is not to accomodate for a defect of the spec,
and where this behaviour is detrimental to the operation of that
implementation (vulnerability or robustness issue) or detrimental
to the interop with other implementations.
With "conflict" in a spec, I refer to distinct statements in a
spec that contradict each other (such as the same symbolic protocol
element is assigned two different values in two seperate locations
of the spec).
With "ambiguity" in a spec, I refer to an omission that precludes
that a certain feature can be implemented at all. Such as a symbolic
protocol element that represents an integer value in a PDU, but
the spec lacks the definition of the numeric value for the
on-the-wire representation.
With "gap" in a spec, I refer to omissions that do not preclude
the implementation, but can lead to unexpected behaviour of an
implementation. This result is vaguely similar to what happens when
a switch() statement lacks a default: case and is unexpectedly faced
with a value that is not covered by case statements. The result
can be "undefined" / "unpredictable", yet remain formally provable
correct with respect to the given specification.
Finally, there are "omissions" in a spec, i.e. properties that a
protocol does and can not provide, yet consumers of the protocol may
believe in "magic security pixie dust" and develop a flawed assumption
about a non-existing protocol property, as it happened in with the
TLS renegotiation. TLS renegotiation being secure/protected against
MitM was a property that was retrofitted into SSLv3/TLS with rfc5746,
and could not possibly have existed "by accident" in any of the existing
implementations. (Although servers that did not support renegotiation
at all never were vunerable to the "interesting" attacks.)
-Martin