> From: Nick FitzGerald [mailto:nick@xxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, June 09, 2004 8:24 AM > > Especially in the case of RFC'ed protocols, because of the > aforementioned "be lenient in what you accept" directive ... the > historical standard has been "accept it and do your best", leasing to > all manner of "compliant but utterly incompatible" shite being foisted > on the world _AND_ boatloads of otherwise really easily avoided dire > security vulnerabilities. What Nick's referring to here is half of the "Robustness Principle", presented by Jon Postel in RFC 793 (STD 7, Transmission Control Protocol): TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. (2.10) Unfortunately Postel did not qualify this rule beyond labelling it "general", or indeed provide any discussion of it at all. (Ironically, it immediately follows the brief discussion of TCP security in the RFC.) I tend to agree with Nick that it has been applied over-broadly. Subsequent RFCs, such as 1123 (Host Requirements), latched onto it eagerly and uncritically (1123 presents it as applying "at every layer of the protocols" (1.2.2)), even when - as in 1123 - they go on to tout it as a security measure! Of course, the Robustness Principle, suitably interpreted, can produce more secure software. As the discussion in 1123 suggests, all software should be written under the assumption that it can receive *any* input, and it should react accordingly. The problem is more in determining what an appropriate response should be. Too often the RP is understood by developers to indicate that the best course is for the application to attempt to compensate for deviations from the protocol and stagger on ahead with its best guess as to the sender's (and user's) desires. This is not the route to secure software. One effect of this common misinterpretation is to site the RP as "be conservative in what you produce, be liberal in what you accept". Substituting "produce" for "do" in the "conservative" clause of Postel's original formulation is a gross error - it restricts what aspects of the implementation are constrained to be conservative, and suggests that care is only necessary when considering the implementation's output, and not its internal behavior. We've had discussions of the RP in various forums before, of course. I believe I made a point similar to Nick's in a posting to Vuln-Dev some time ago, but the topic is still vital, as many developers take the RP (often in its misquoted form) as gospel. -- Michael Wojcik Principal Software Systems Developer, Micro Focus
