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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Feb 2005 07:26:36 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jim Schaad

> Blake,
> 
> MASS I think is going to fail because they are trying to 
> solve the problem without upsetting anybody by adding some 
> attachements.  

On the other hand we do intend to upset plenty of people by expecting list
serves to work properly.

The difference is context. The demand for cryptographic email security has
never been as widespread. S/MIME could not expect the rest of the world to
change. DK/IIM can.

I do not believe it is possible for MASS to fail, there will not be a MASS
until it is clear that the spec has been deployed.

> Since MASS is not using S/MIME in any way shape or form, I 
> doubt you are offending them.

I think that one of the big mistakes that has been made in email crypto
security (besides the S/MIME vs PGP war) is trying to combine signature and
encryption in one spec. This led to all sorts of restrictions that are
inevitable with encryption being pushed onto signature.

DK/IIM will provide a signature format and a policy layer, there is no
reason to go and repeat the work of S/MIME & PGP for encryption, just hook
the existing formats into the policy framework. The biggest hole in email
encryption schemes is the lack of a policy layer. Each time it is proposed
in the IETF someone wet blankets it by saying 'that's haaard', like so what?

So DK/IIM becomes a lower barrier to entry route for crypto secured email.
Once folk are signing at the domain level they will want to encrypt at the
domain level. Domain level crypto security will naturally lead to some
people going to per account level. 

I see DK/IIM as being a means of driving deployment of S/MIME encryption.
The only reason that I think we might not get to S/MIME is if we end up
going straight past it to DRM type formats which actually make a lot of
sense for messaging security. But that is not likely given the encumberances
situation.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Feb 2005 08:58:51 -0800

Why do you think this is a problem? Is it because you think that the
messages will end up mangled in transit or because there has to be a user
interface component?

If the latter I agree but I think the answer is to layer on a CA
authenticated 'letterhead' for signed messages from accredited sources using
the X.509 logotype extension.

	Phill

> -----Original Message-----
> Sent: Wednesday, February 02, 2005 1:12 AM
> To: 'Blake Ramsdell'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Protection of header elements in an S/MIME message
> 
> 
> 
> Blake,
> 
> It's actually my opinion that MASS is a non-starter because 
> they are trying too hard to makes sure nobody sees that it 
> exists.  I think they should take the hit of saying -- see I 
> have MASS implemented.  I guess I get to try and be loud at the IETF.
> 
> jim 
> 
> > -----Original Message-----
> > From: Blake Ramsdell [mailto:[email-masked]]
> > Sent: Tuesday, February 01, 2005 12:37 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Protection of header elements in an S/MIME message
> > 
> > Jim Schaad wrote:
> > > Actually given the text that you have in the message draft,
> > I consider
> > > it to be useless and I don't know of anybody who is going
> > to be able
> > > to deal well with the message.  Its not very backwards compatable
> > > (i.e. no current implementation will handle it well) and 
> > its not well
> > > defined for how header comparision is done.
> > 
> > Ouch. But yes, you're absolutely correct that nobody will be
> > able to deal well with the message (with the definition of 
> > "well" being defined as "merging the headers in an 
> > unambiguous way that represents both the intent of the sender 
> > and the desire of the receiver").
> > 
> > I am offending them in that the way I would solve this
> > problem is by putting headers in an inner attachment, which 
> > you've pointed out (twice) is a non-starter for them. If we 
> > try to come up with a unified mechanism for doing this, my 
> > strawman would be:
> > 
> > 1. Inner message/rfc822
> > 
> > 2. Rules for merging headers
> > 
> > 3. What to do about required external headers and how to
> > placate people who require them ("placebo" headers)
> > 
> > If anyone's interested, there are at least two relevant 
> threads in the
> > archive:
> > 
> > "Protecting fields via message/rfc822 and merging issues"
> > 
> > "The subject line leakage problem"
> > 
> > Blake
> > --
> > Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
> > 
> > 
> 
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 11 Feb 2005 12:08:55 -0800

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.