Why the exponent 3 error happened:

[Victor Duchovni]

On Thu, Sep 14, 2006 at 11:25:11AM -0400, dan at geer.org 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 majordomo at metzdowd.com