Re: the 8-bit dilemma

Brad Knowles (brad@azathoth.ops.aol.com)
Wed, 28 Feb 1996 20:14:45 -0500 

On Feb 28,  4:34pm, Edward A. Russell wrote:

> Do you mean signing the fact that this is an audio object for example?
> So I would know if someone changed the type from audio to video?

    Content-type is not the only header field to potentially be
protected, and yes we're talking about making sure that none of them
can be changed.

    For me, the issue is that when you sign something, *nothing* about
that message as it originated should be able to be changed without the
signature also having to be changed to match, and since we're assuming
that finding another valid signature that will match the Message
Integrity Check value for the now modified message is a very hard
problem to solve, so the signature won't verify.


    Or, at least, the user should be able to configure things to that
nothing can be changed without being detectable by the signature now
failing to verify, and if they choose to relax their security so that
this is no longer true, then perhaps they should have that option.


    This is why IMAP needs to be changed so that it can access the
content-type and other header fields in addition to the objects
themselves.

>                                                                   That
> seems like a fairly esoteric benefit when weighed against the fact
> that I am unable to save encrypted or authenticated objects to disk
> and then use them outside of my mailer.

    How do you guarantee this?  The mailcap file (or whatever) that
tells the MIME agent what to pass the secure part off to for
decryption verification is just calling a program.  What keeps me from
changing my mailcap file so that a wrapper program is called that lets
me shell out and save the data?


    Unless you hard-code all this stuff into the MIME agent, there's
no way to keep a table-based dispatch system from being compromised in
this fashion.  And even if you do hard-code it all in, what keeps me
from moving the real binary somewhere else and then putting my Trojan
Horse in?  I mean, this approach can even be used without the user
neessarily *wanting* it to happen.

> I always thought of transport security as being handled by Secure
> Socket Layer.  We are moving the concept of "transport" up a little
> into the application space.  I'm not sure what OBJECT security would
> be seperate from PGP, etc.  I would hope not yet another wrapper of
> security.

    That's network-layer transport security.  Unless you want to tie
SSL (or Secure Sockets) to your sendmail implementation (or whatever
your SMTP MTA is), then there is the need to also do "transport-level"
security for the application layer as well, since the message(s) may
be sent over some links that are not secure.

    In other words, both link-level and end-to-end encryption are
important and useful in their own ways in this kind of scenario.

-- 
Brad Knowles                           MIME/PGP: BKnowles@aol.net
    Mail Systems Administrator          <http:www.his.com/~brad/>
    for America Online, Inc.                   Ph: (703) 453-4148