Re: IMAP vs. multipart/signed

Brad Knowles (brad@his.com)
Sun, 25 Feb 1996 00:39:55 -0500 

At 10:42 AM 2/24/96, Mark Crispin wrote:>

> 1) If the MIME structure of the message is obscured (e.g. encrypted) by a
> security format, then an IMAP server which does not have the knowledge to
> decypt the security format can not parse the MIME content of the message.  But
> giving the IMAP server this knowledge moves the point of trust from the end
> user to the IMAP server, and leaves the IMAP server -> user channel exposed.

    IMO, the encrypted format needs to have the MIME header info
in either encrypted or plaintext, depending on the desires of
the originator (or the organizational policies of their
employer).  If the content-type is visible, then the IMAP client
can make more intelligent decisions regarding how to handle the
data (both data size and content).  If the content-type is not
visible, then the IMAP client is obviously not capable of making
the more intelligent decisions it was intended to be able to
make (in a general sense) although the job of doing traffic
analysis on the MIME header information becomes more difficult.

    If you allow both the client and server models of trust and
decryption, then there is the possibility of the server -> user
channel being exposed, and this was explictly acknowledged.
This could be dealt with by additional link-level encryption
between the server and the user, but this might bring up
exportability issues if the user and the server are across
political boundaries.  I'm not sure if we necessarily want to
concern ourselves at the moment with this level of additional
link-layer encryption, especially since IMAP may not be the only
access protocol that could be affected (in the future, anyway).



    Another point that was brought up at the workshop was the
necessity to protect both the channels between endpoints and the
endpoints themselves.  It does no good to make the channels
between impregnable if it's a simple matter to store all the
information locally in an unencrypted format which could get
blasted across local wires in a X terminal or diskless
workstation fashion, or if a Trojan Horse could easily be
attached that would collect local unencrypted data and secretly
send that back to some third party.  Things like Web Browsers
that allow things like Java or JavaScript to collect arbitrary
bits of data are particularly troublesome.

    I'm not sure that there is necessarily anything we can do at
the moment to help prevent this problem, but I think we
definitely need to keep this in mind as we discuss protocol
standards and try to make sure that we don't at least make it
easier for the endpoints to be compromised.

        -Brad