Re: Security Problems

Brad Knowles (brad@his.com)
Wed, 6 Mar 1996 05:39:45 -0500 

At 2:14 AM 3/6/96, Terry Ritter wrote:

>  I argue that *enciphered* data is *not* just another data type,
>  but an inherently different *level* of description.  Indeed, it
>  seems to be the attempt to "tack on" encryption which leads to
>  these bizarre calls for descriptions of the data *both* inside
>  *and* outside the encryption.

    So far as I know, no one on this list is advocating that we just
"tack on" encryption.  In fact, I submit that some of us are arguing
that the support for encryption needs to be extremely tightly
integrated with MIME, something that appears to be lacking in many
existing "secure email" standards.

    It is your desire for totally unlabeled objects totally dependant
on out-of-band communications to give them the critical context they
need that appears to be diametrically opposed to the entire concept
of MIME, however.  Try reading RFC 1847.  Try reading the MOSS
specification or the latest PGP/MIME specification.  Take a look at
the kinds of data labelling we're talking about.

>  But in-between these levels I would place an encryption level,
>  which would have key-delivery, and data ciphering sub-levels.

    And the encryption part needs to be able to pass information back
to the MIME parser which needs to be able to recurse and call the
encryption part again, ad infinitum.  The other choice is to make the
security/encryption part integral to the MIME parser, but that gets
hairy if you ever have to replace the encryption engine(s).

    I submit that we should leave the parsing of MIME to those best
suited for it (existing MIME MUAs) and we should create a mated part
that drops in and acts as a full partner in securing every aspect of
what that MIME MUA does.  Obviously, some MIME MUAs will be better
suited for this than others, but there's only so much we can do to
accomodate them, and people that really care about security and
privacy in email will either upgrade or switch.

>  Okay up to the introduction of "encryption and authentication"
>  which are not MIME.  Encryption under MIME is something I believe
>  is *not* clearly thought out, and is *not* implied by MIME
>  development, *even* *if* the original developers thought it
>  *would* work out.

    Check the MOSS spec.  Not *everything* is there, but a lot of
problems have already been solved by a pretty much fully integrated
security standard for MIME.  The problem was that there was only one
reference implementation that was exportable but not "secure" (by my
definition) and that vendor support was lacking.

>  Perhaps you could explain to me what *you* mean by "*some*
>  degree of security":
>
>  Does it mean that while data are to be transported securely, the
>  data type is generally expected to be exposed by design?

    No.  The data type needs to be able to be exposed, if the user
desires it.  But by default it would be opaque.  The specific
cryptographic algorithm used to make the object opaque cannot itself
be opaque, per RFC 1847 (which I believe that the IMC is proposing be
modified slightly and turned into a standards-track document, or
something approaching that in practice).

>  Does it mean that a user is restricted to using only those data
>  ciphers which have been approved and registered?  And by whom?

    A user should be able to use whatever ciphers they have available
to them and implemented by their UA, however if they want the person
at the other end to be able to read it, they'd damn well better
conform to the registered algorithms known to be understood by the
entity at the other end, or have obtained additional knowledge
through other means.  But the initial starting point must always be
that public registry.

>  Does it mean that those who use secure e-mail must necessarily
>  and by design announce this fact in plaintext headers?

    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.

>  I think we can all agree that, all things being equal, it would
>  be *much* preferable to hack MIME a little and get secure e-mail,
>  *provided* that is realistic.  But the result has to work.

    But this isn't going to work, and I hope everyone here realizes
that.  If it did, there would be no need for this mailing list, and
there would have been no need for the Workshop.  There are some
issues left to resolve, and although I believe that we can find
solutions to the problems that I perceive as facing us today, I'm not
yet convinced that we know what all those problems are.

>  On the other hand, if the result has seriously flawed security,
>  or unnecessary vulnerability to surveillance, maybe it makes sense
>  to back up and see if we really want to go down this particular
>  road.  Sometimes we don't know how bad the road is until we get
>  there.

    Right, which is why you should never default back to one
particular encryption algorithm as a part of the standard, otherwise
the baseline minimum will become the effective maximum (because you
can't guarantee that anyone has anything better than the minimum) and
you haven't done much useful work.  Everything has to start from the
central registry.

--
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/>