[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