[Michael I Bushnell: Proposed RFC `Guidelines for the Secure Operation of the Internet']
Stephen D Crocker <crocker@tis.com> Fri, 17 May 1991 12:20 UTC
Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa03291; 17 May 91 8:20 EDT
Received: from TIS.COM by NRI.NRI.Reston.VA.US id aa03115; 17 May 91 8:11 EDT
Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA06705; Fri, 17 May 91 08:09:13 EDT
Message-Id: <9105171209.AA06705@TIS.COM>
To: spwg@NRI.Reston.VA.US, saag@tis.com
Subject: [Michael I Bushnell: Proposed RFC `Guidelines for the Secure Operation of the Internet']
Date: Fri, 17 May 1991 08:09:12 -0400
From: Stephen D Crocker <crocker@tis.com>
In case you didn't already see this, these are interesting comments. Rich, Barbara or others: We should attempt to explicate or respond. Steve ------- Forwarded Message Date: Fri, 17 May 91 01:36:30 -0400 From: Michael I Bushnell <mib@gnu.ai.mit.edu> To: postel@isi.edu, iab@isi.edu Cc: iesg@NRI.Reston.VA.US, ietf@isi.edu Subject: Proposed RFC `Guidelines for the Secure Operation of the Internet' This document suffers from a serious flaw, which causes it to be very difficult to use. It fails to describe which local security features are advice to participants in the internet for their own good, and which features are things all good net-citizens should do. For example, it says: (ii) Adequate security controls must be implemented. At a minimum, this means controlling access to systems via passwords -- and instituting sound password management! -- and configuring the system to protect itself and the information within it. Does this mean that a site which chooses not to exercise strict password management, and is willing to assume the risk that it might be damaged, is being a bad citizen, or is it simply an indication that such a site needs to be aware of the risk it is undertaking? If this is merely advice to system administrators, then that is well and good, and, in fact, it is good advice. But a better wording would be "Without adequate security controls, systems are can be highly vulnerable. Minimal security necessary to prevent severe vulnerability includes passwords (with sound password management) and proper system configuration." Such a wording would leave open the possibility that a site is willing to be vulnerable, and accepts the risk itself. Another example: 4) Vendors and system developers are expected to provide systems which are sound and have adequate security controls. Vendors and system developers should evaluate systems in terms of security controls prior to the introduction of the system into the computing community. Products should be labeled according to security controls that are present. Vendors have a positive obligation to repair flaws in the security relevant portions of the systems they sell for use in the Internet. Vendors are also expected to cooperate with the Internet community as far as making security related fixes available to the entire community in a timely way. Does this section mean that I, as an OS developer, am obligated to provide and maintain security features, or is it an indication that a "good" OS developer does so, or is it simply helpful advice to people selling and writing software? My software is not sold. Does this change the positive obligation at all? Here's another: 5) Users, sites, networks and vendors are expected to provide mutual security assistance. This doesn't even happen from CERT! CERT consistently refuses to explain the nature of security flaws in vendors' software, despite full knowledge of the nature of the flaw. For example, the recent telnetd bug had fixes posted for SunOS, but there was no description of the nature of the bug. My email queries went unanswered. I had to find out the nature of the bug, so I could check our software for it, from the grapevine and people who read comp.unix.wizards. If CERT can't be expected to provide security assistance, who can? If CERT is to be the standard for this kind of assistance, then some kind of distinction needs to be made between helping people deal with existing attacks (which CERT does well) and helping people avoid future attacks (which CERT does spottily, at best). I don't expect an immediate answer to these questions. I'm trying to point out what I see as a serious flaw in the document. I'd like to see the IESG revise it, and make it much clearer which things are mandatory, which are part of good net citizenship, and which are simply helpful advice. I hope it isn't too late for this to happen. I'd hate to see policies get enshrined without an understanding of the various security requirements the diverse systems on the internet have, especially including open systems. Something else to consider: At some point, theoretically, the internet will be accessed through commercial service providers. If systems are going to be required to have some particular security level, that become useless when anyone gets on the net. A good analogy comes from usenet. In the "early days", system administrators were all "good people", and you could implicitly trust them. Many, many sites honored all `rmgroup' messages without question. Now that usenet has branched out, and become wildly successful, one can no longer expect other system administrators to secure one's own news system. Almost nobody honors all `rmgroup' messages anymore. When the internet becomes this spread out, will we still be relying on other systems to provide security for our own, or will we realize that other systems fundamentally cannot be expected to secure themselves merely for our own sake? -mib ------- End of Forwarded Message
- [Michael I Bushnell: Proposed RFC `Guidelines for… Stephen D Crocker