On Thu, Sep 14, 2006 at 11:25:11AM -0400, [EMAIL PROTECTED] wrote: > > "James A. Donald" writes: > -+----------------------- > | <snip> > | > | ASN.1 provided additional redundant information, making > | possible unexpected data layouts that should not > | normally happen. It had too much expressive power, too > | much flexibility. It could express cases that one does > | not expect to deal with, could flex in more ways than > | one's software is likely to be written for. > | > | <snip> > > Sir, There is a lesson here as important as > Fred Brook's "Adding people to a late project > makes it later" and I urge you to put this in > some form of "print" at your earliest capability. > No, not urge but rather beg.
If so, I fear we are learning the wrong lesson, which while valid in other contexts is not pertinent here. TLS must be flexible enough to accommodate new algorithms, this means that the data structures being exchanged are malleable, and that implementations must validate strict adherence to a specifically defined form for the agreed algorithm, but the ability to express other forms cannot be designed out. This, in my view, has little to do with ASN.1, XML, or other encoding frameworks. Thorough input validation is not yet routinely and consistently practiced by most software developers. Software is almost invariably written to parse formats observed in practice correctly, and is then promptly declared to "work". The skepticism necessary to continually question the implicit assumption that the input is well-formed is perhaps not compatible with being a well-socialized human. The attackers who ask the right questions to break systems and the few developers who write truly defensive code are definitely well off the middle of the bell-curve. It is not just PKCS#1 or X.509v3 that presents opportunities for crafting "interesting" messages. MIME, HTTP, HTML, XML, ... all exhibit similar pitfalls. Loosely speaking, this looks like a variant of Goedel's theorem, if the protocol is expressive enough it can express problematic assertions. We can fine-tune some protocols to remove stupid needless complexity, but enough complexity will remain to make the required implementation disciple beyond the reach of most software developers (at least as trained today, but it is not likely possible to design a training program that will a preponderance all strong defensive programmers). -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAIL Morgan Stanley confidentiality or privilege, and use is prohibited. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]