Re: Security Problems

Brad Knowles (brad@his.com)
Thu, 7 Mar 1996 03:22:34 -0500 

At 12:52 AM 3/7/96, Terry Ritter wrote:

>  OK -- suppose we register a new MIME type "application/special"
>  (or -- if pushed -- "application/X-special").  To avoid announcing
>  "this is ciphertext" in the open headers, it is necessary that an
>  enciphered payload *not* be the only use for this tag.

    This is diametrically opposed to the nature of MIME.  Either you
have totally unlabelled (or otherwise undetectable) encryption
algorithms or you don't, but RFC 1847 leaves no room for negotiation
-- at a minimal level, the encryption algorithm within a MIME
framework *will* be labeled.

    End of discussion.

>  I see no "ad infinitum" requirements.  One would expect that
>  virtually all traffic would need just two levels.

    The moment you place a limit like this on a system, a user will
find a reason why they want (or need) more than you provide.
Therefore, it is IMPERATIVE that the standard be designed so that it
has no inherent limit on the level of recursion allowed, and should
in fact specify that all conformant implementations should be capable
of handling a ridiculously high amount of recursion, which could be
tested for conformance.

>  If MOSS does not handle the security issues I have brought up,
>  then I would expect to bring that out.

    Read the spec before you attempt to discuss any alternatives.

>  Since I could not allow a "ciphertext" indication in open headers,
>  I could not use either "multipart/signed" or "multipart/encrypted"
>  and therefore need not get into any supposed limitations imposed
>  by RFC 1847.

    We have defined that RFC 1847 is our baseline for how this shall
be done in a MIME framework.  This was done at the workshop you
obviously didn't attend.  Therefore, no discussions outside of RFC
1847 (as proposed for minor modification) are appropriate within this
working group.

> >    To the degree that RFC 1847 requires that the cryptographic
> >algorithm be specifically named, yes.  As mentioned by others, so
> >long as this algorithm is not set in stone, it doesn't make you
> >noticably weaker for those who have the power to break your
> >cryptography anyway, and doesn't noticably help those who don't have
> >that power.
>
>  As far as I am concerned, this is a killer:

    We're not requiring that all Secure Internet Email be done
according to RFC 1847, or else.  We are saying that this is the
framework we shall use for doing security in a manner most consistent
with MIME, and that we will take multiple existing and incompatible
standards that purport to do essentially the same things and come up
with one canonical standard way of foing this.  People are certainly
free to use other methods, but those other methods do not fit within
the self-defined purview of this particular working group.

--
Brad Knowles,                                  MIME/PGP: brad@his.com
    comp.mail.sendmail FAQ Maintainer     <http://www.his.com/~brad/>
        finger brad@his.com for my PGP Public Keys and Geek Code
The comp.mail.sendmail FAQ is at <http://www.his.com/~brad/sendmail/>