Subject: RE: Best practice for data encoding?

From: "Gray, Eric" <[email-masked]>
Date: Mon, 5 Jun 2006 20:59:32 -0400

Steven,

	I'm not sure what you mean by saying that a problem that is
highly complex should not be solved (or, at least, that we should
consider not solving it).  That seems like a cop-out.  Minimally,
every problem we've ever faced, we've tried to solve (where "we"
refers to us weak-kneed Homo Sapiens) - no matter how hard it was
to do so - and I like to think that is the right thing to do.

	In fairness, I am reasonably sure that point 3 in RFC 1925 
refers to making a complex solution work, even if a simpler answer
might be found, simply because enough people want that solution.  

	It does not - IMO - rule out solving complex problems using 
as simple a solution as possible, however complex that might be.

--
Eric

--> -----Original Message-----
--> From: Steven M. Bellovin [mailto:[email-masked]] 
--> Sent: Monday, June 05, 2006 8:21 PM
--> To: David Harrington
--> Cc: [email-masked]
--> Subject: Re: Best practice for data encoding?
--> 
--> On Mon, 5 Jun 2006 20:07:24 -0400, "David Harrington"
--> <[email-masked]> wrote:
--> 
--> > Hi 
--> > 
--> > The security problems identified in
--> > http://www.cert.org/advisories/CA-2002-03.html "Multiple
--> > Vulnerabilities in Many Implementations of the Simple Network
--> > Management Protocol (SNMP)" are not caused by the 
--> protocol choice to
--> > use ASN.1, but by vendors incorrectly implementing the 
--> protocol (which
--> > was made worse by vendors using toolkits that had the problems).
--> > 
--> > If "Multiple Vulnerabilities in Implementations" were 
--> used to condemn
--> > the encoding methods of protocols that have been incorrectly
--> > implemented, then we would have to condemn an awful lot of IETF
--> > protocols as being very (security) bug prone: 
--> > 
--> 
--> Works for me....
--> 
--> More precisely -- when something is sufficiently complex, 
--> it's inherently
--> bug-prone.  That is indeed a good reason to push back on a 
--> design.  The
--> question to ask is whether the *problem* is inherently 
--> complex -- when the
--> complexity of the solution significanlty exceeds the 
--> inherent complexity of
--> the problem, you've probably made a mistake.  When the 
--> problem itself is
--> sufficiently complex, it's fair to ask if it should be 
--> solved.  Remember
--> point (3) of RFC 1925.
--> 
--> I'll note that a number of the protocols you cite were 
--> indeed criticized
--> *during the design process* as too complex.  The objectors 
--> were overruled.
--> 
--> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 6 Jun 2006 01:40:03 -0400

> as simple a solution as possible, however complex that might be.

I meant exactly what I said.  The reason to avoid certain "solutions" is
that you'll then behave as if the problem is really solved, with bad
consequences if you're wrong -- and for some problems, you probably are
wrong. Read David Parnas' "Software Aspects of Strategic Defense
Systems" (available at
http://klabs.org/richcontent/software_content/papers/parnas_acm_85.pdf);
also consider the historical record on why the US and the USSR signed a
treaty banning most anti-missile systems, and in particular why the
existence of such systems made the existing nuclear deterrent standoff
unstable.

Note carefully that I didn't say we shouldn't do research on how to solve
things.  But doing research and declaring that we know how to do something
are two very different things.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

06 Jun 2006 01:40:08 -0400
Date: Tue, 6 Jun 2006 01:40:03 -0400
From: "Steven M. Bellovin" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Organization: Columbia University
Cc: [email-masked]
Subject: Re: Best practice for data encoding?

> as simple a solution as possible, however complex that might be.

I meant exactly what I said.  The reason to avoid certain "solutions" is
that you'll then behave as if the problem is really solved, with bad
consequences if you're wrong -- and for some problems, you probably are
wrong. Read David Parnas' "Software Aspects of Strategic Defense
Systems" (available at
http://klabs.org/richcontent/software_content/papers/parnas_acm_85.pdf);
also consider the historical record on why the US and the USSR signed a
treaty banning most anti-missile systems, and in particular why the
existence of such systems made the existing nuclear deterrent standoff
unstable.

Note carefully that I didn't say we shouldn't do research on how to solve
things.  But doing research and declaring that we know how to do something
are two very different things.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb