MIME polymorphism

The two major e-mail security protocols currently proposed - S/MIME 
and PGP/MIME - both build on the fundamental framework of 
multipart/signed messages specified in RFC 1847.  In this framework, 
the data to be signed is formatted as a single MIME part (which may, 
of course, contain nested sub-parts).  This MIME part is then hashed 
for the signature.  The hash does, in particular, include all the 
meta infomration present on the MIME level, including the body 
part's content type.  That way, the signature does, for instance, 
include the information whether some PostScript code which was 
signed should be interpreted by a postscript interpreter for display 
(application/postscript), or whether this code should just be 
displayed as plain text (text/plain). In theory, with 
multipart/signed, the actual data and the information how it must be 
interpreted is both signed and protected.
This theory fails on two levels: First, knowing a file's content 
type is not sufficient to guarantee correct interpretation.  This 
has been demonstrated before; think about differences in the 
interpretation of certain special characters when documents are 
exchanged between some Microsoft Word versions for the Windows and 
Macintosh platforms. [4]
Second, the theory is based on the assumption that the 
interpretation of the MIME meta information contained in Content-* 
headers is well-defined. This assumption is violated with malformed 
MIME messages which contain contradictory information: When there 
are, for instance, multiple boundary parameters for a single 
multipart/* attachment, implementations will generally follow the 
mantra of being liberal in what they accept, and just choose one.
When there are multiple Content-Type headers present on a single 
attachment, implementations will likewise be liberal, and choose one 
(or even mix information from the two headers).
Since the choices made differ between MIME implementations, it is 
for instance easily possible to create an e-mail mesage with a 
multipart/mixed body which seems to contain different content, 
depending on whether it's displayed with mutt [5] or pine [6].
Note that this problem does not only apply to digital signatures, 
but also to virus scanners: If these try to be liberal with respect 
to malformed MIME messages, they may easily check attachments for 
viruses which will never be seen by users - and, likewise, they may 
not scan those attachments which are actually displayed by users' 
software.
To prevent this problem from occuring, security services must not be 
liberal in what they accept, or try to hide possible problems from 
users. Instead of software silently making choices, ambiguities must 
be treated as malicious, and users must be warned.

References:

1. Galvin, Murphy, Crocker, Freed: Security Multiparts for MIME: 
   Multipart/Signed and Multipart/Encrypted. RFC 1847, October 1995.
2. Freed, Borenstein: Multipurpose Internet Mail Extensions (MIME) 
   Part One: Format of Internet Message Bodies.  RFC 2045, November 
   1996.
3. Elkins, Del Torto, Levien, Roessler: MIME Security with OpenPGP. 
   RFC 3156, August 2001.
4. Fox, Zu einem prinzipiellen Problem digitaler Signaturen, 
   Datenschutz und Datensicherheit (DuD) 7/1998, pp. 386-388.
5. Mutt home page: <http://www.mutt.org/>

6. Pine Information Center: <http://www.washington.edu/pine/>

--
Thomas Roessler                        http://log.does-not-exist.org/