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