Re: Security Problems

Barton E. Schaefer (schaefer@z-code.ncd.com)
Tue, 5 Mar 1996 18:06:36 -0800 

On Mar 5,  4:31pm, Terry Ritter wrote:
} Subject: Re: Security Problems
}
}  How can "hiding encryption" have any effect on "modularity and
}  flexibility"?  [...]
} 
}  While I cannot speak to "tight integration with MIME," [...]

I think that's the problem.

}       I believe that there is no technical need to expose the fact
}       of ciphering in open headers, and there is a substantial 
}       public responsibility to not do so.  

Quoting for a moment from RFC1521 (because it can be summarized more
briefly than the latest IETF MIME draft):

----------

   [....] this document is designed to provide facilities to
   include multiple objects in a single message, to represent body text
   in character sets other than US-ASCII, to represent formatted multi-
   font text messages, to represent non-textual material such as images
   and audio fragments, and generally to facilitate later extensions
   defining new types of Internet mail for use by cooperating mail
   agents.

      [....]  It is important to note that compatibility with existing
      standards AND robustness across existing practice were two of the
      highest priorities of the working group that developed this
      document.  [....]

   A mail user agent that is MIME-conformant MUST:

      [....]

      3.  Recognize and interpret the Content-Type header field, and
      avoid showing users raw data with a Content-Type field other than
      text.  [....]

   A user agent that meets the above conditions is said to be MIME-
   conformant.  The meaning of this phrase is that it is assumed to be
   "safe" to send virtually any kind of properly-marked data to users of
   such mail systems, because such systems will at least be able to
   treat the data as undifferentiated binary, and will not simply splash
   it onto the screen of unsuspecting users.  [....]

----------

Pay particular attention to the phrases "facilitate later extensions,"
"robustness across existing practice," and "properly-marked data."

Unless something radical has changed in the last week or so, the
standards that we're trying to agree upon here are intended to be
usable in a MIME framework and therefore to support the design goals
of MIME.  I believe this implies several things:

1.  It MUST NOT be assumed that knowledge of any given extension (in
    this case, a cryptography system) is tightly integrated with any
    mail client.  It must be possible to *extend* an existing MIME
    client, through the regular MIME rules, to enable handling the
    extension (in this case, encryption and authentication).

2.  The client MUST be able to identify those cases in which any given
    extension should be applied, and MUST NOT be required to apply
    processing for such an extension in cases where it is irrelevant.

3.  A client which does not support any given MIME extension MUST be
    able to identify non-text objects and avoid displaying them.  It
    is NOT ACCEPTABLE to interleave unlabeled non-text data with plain
    text (unless the entire object, including the text, is labeled as
    non-text and therefore not displayed).

It's a waste of everyone's time to debate on cryptographic grounds the
merits of a system that cannot meet the above criteria.  It's certainly
worthwhile to hear about such a system, and it's quite reasonable for
persons who find the MIME-based security mechanisms to be insufficient
to agree to employ such a system among themselves.  It's NOT worthwhile
to argue any further that persons who desire *some* degree of security
within the MIME framework should be required to abandon the advantages
of that framework.

So tell me, oh mystical Consensus of the List:  Are we talking about
resolving the issues of implementing interoperable security in a MIME 
framework, or are we rehashing every for-the-public-good argument that's
ever been put forth by seat-belt and motorcycle-helmet advocates, with
appropriate substitution by the phrase "ciphertext" throughout?

This is not to say that there's no merit to the latter, but I think our
chances of succeeding with the former are slim enough already.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts