ietf-smime
[Top] [All Lists]

RE: Protection of header elements in an S/MIME message

2005-02-11 13:09:18

A good principle to help decide what information should be kept confidential
and what should be en-clair is to consider what information is supplied by
the user directly on a per message basis.

I believe that any information that is input directly by the user is likely
to contain confidential information. The subject line of the message is
really an abstract of the message body and should really be considered
content rather than routing information.

Equally if there are calendaring interfaces that use message headers to
carry appointment info then this needs to be encrypted as well (I don't know
what the state of these is at the moment, only that they are currently
proprietary).


I think that it is also essential that we consider ways that a secure email
can provide the information needed by a email edge server acting as a
firewall to determine whether the email is safe, i.e. either provide a
binding pledge that the email does not contain active content or if it does
provide the necessary level of authentication. For example if I control the
email clients used in my enterprise then I can require everyone to use a
client that will NOT execute Javascript, activeX, word macros or any other
form of active content if the message is marked 'NO-EXECUTABLE-CODE' and in
that case will send back a security exception.

The problem with end-to-end security in its absolutist form is that it has
been allowed to trump the needs of firewalls. 

Perimeter defense has empirically proved its value today. Practically every
security professional in the field agrees that perimeter defense provides
some value. End to end security has failed to secure deployment or prove its
value on an extended scale. Therefore it is necessary for end to end
security solutions to provide the information required by single-perimeter
security and multiple-perimeter cellular security systems. Otherwise the end
to end systems will not be adopted.