Subject: Header Protection for S/MIME

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 1 Oct 2007 09:29:43 -0400

The authors of the following draft wanted me to bring their draft to your
attention:

http://www.ietf.org/internet-drafts/draft-liao-smimeheaderprotect-00.txt

spt

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Oct 2007 12:12:49 -0400

I have not seen any discussion of this document on this list.  It is
proposing a very different approach to a problem that was discussed on
this mail list.  The current MSG specification includes a very
different solution to this problem.

We should be talking about this proposal ....

Russ

At 09:29 AM 10/1/2007, Turner, Sean P. wrote:

The authors of the
following draft wanted me to bring their draft to your attention:

spt

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 15 Oct 2007 12:44:37 -0400

Perhaps there has been no discussion because there is nothing to
complain about.  Controversy, or "clash" in media terms, is what sells.
The document appears to be a well-thought-out approach to providing
header integrity protection (but not confidentiality, for which
encapsulation is required).  Unlike the current encapsulation approach,
it is compatible with header-protection-unaware applications, and it
avoids the issue of how to represent inner and outer headers to users by
not using an outer header in the first place.

In short, what's not to like, and when can we buy it?  Seriously, if
this is a straw poll for accepting this proposal as a work item and
progressing it toward RFC, I vote yes.

And if we need to spice things up with a little clash, "fielname" is
misspelled in section 2.1.

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, October 11, 2007 12:13 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Header Protection for S/MIME

I have not seen any discussion of this document on this list.  It is
proposing a very different approach to a problem that was discussed on
this mail list.  The current MSG specification includes a very different
solution to this problem.

Russ

---

From: Blake Ramsdell <[email-masked]>
Date: Mon, 15 Oct 2007 19:28:19 -0700

> not using an outer header in the first place.

Silence can also indicate apathy. So let's start diving into whether it's so
cool that there's nothing to say, or we don't care so much that there's
nothing to say.

I read this draft over, and indeed, it documents a new approach to header
protection, and it appears to be heavily influenced by the DKIM approach to
header processing. To hit the high points:

* A new signed attribute is introduced, which contains

  * An algorithm identifier to indicate a canonicalization algorithm to be
    used when presenting the headers to the digesting algorithm

  * A digesting algorithm identifier

  * An ordered list of headers, multiple instances of a header are indicated
    by listing the header name more than once

  * A digest of the canonical values of those headers

* Uh, that's pretty much it

Now, there's some things in here that need fixing. I'm sure there's some ASN.1
fun, especially debating NULL vs. absent parameters for
CanonAlgorithmIdentifier. I'm sure there might be some opinions about whether
the digest algorithm should be specified in the outer SignedData
digestAlgorithms list. And the security goals need some work -- "The main
security goal of mail message header protection is not to protect the whole
RFC 2822 header against manipulation, but to make it possible for the
receiving client to detect which headers have been changed." isn't exactly true,
you can't figure out which headers have been changed, only that "something in
the list of headers that were protected with the digest has changed".

One appealing aspect is that it is compatible with current practice -- it is
incremental functionality that oblivious clients will simply skip. And the
cost of this approach is fairly little -- slightly increased message size.

OK, so I'll start. Is there some goal that we can achieve with this mechanism
that is better than the "just wrap a whole message/rfc822 and lord knows how
you merge the resulting headers" approach that is the current practice?

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 16 Oct 2007 10:52:47 -0400

Security is not an end in itself, it supports and facilitates
"mission applications" that do something meaningful for end
users.  End users want email (at least the older ones do, younger
folks use instant messaging), and I would think if the
goal is to have email that "just works" in terms of spam
resistance, the integrity attribute approach is much more
natural than S/MIME's confidentiality-oriented encapsulation.

I have not followed DKIM at all and am not in a position
to comment on what the spambuster community wants.  But if
they want security and ask S/MIME for help (in the form of
an already-written I-D, not just a vague request), it seems
that apathy from us is an inappropriate response.  We should
1) tell them why what they want is wrong from a security perspective,
2) accommodate their request by adopting the I-D, or
3) let them do their own security outside the S/MIME WG.

I don't think (1) applies, so do we want to help them (2) or
tell them we can't be bothered (3)?

Dave

-----Original Message-----
> From: Blake Ramsdell [mailto:[email-masked]]
>
> OK, so I'll start. Is there some goal that we can achieve with
> this mechanism that is better than the "just wrap a whole
> message/rfc822 and lord knows how you merge the resulting
> headers" approach that is the current practice?

---

From: Jörg Schwenk <[email-masked]>
Date: Thu, 18 Oct 2007 16:51:17 +0200

Hi,

to start the discussion on our draft [1], I'd like to explain the idea and
the advantages it has (in our opinion) over the solution proposed in RFC
3851.

Idea

The idea is to put Information about the header in a CMS hashed subpacket.
Legacy mail clients may simply ignore this subpacket (i.e. they don't
recompute the hash value contained in this packet). Conforming mail clients
compute an additional hash value over some normalized header fields, and
include this hash value in CMS signature verification.

Advantages

1. Backward compatibility: Legacy mail clients are not affected by the
introduction of an additional signed subpacket. (This is in contrast to RFC
3851, where legacy clients will display only the outer header lines, without
check.)

2. Flexibility: Any combination of header lines can be protected. This may
range from introducing a single hashed subpacket for the most important
header lines (e.g. From, Sender, To, CC, Date, Subject) to separate hashed
subpackets for each line. Conforming clients may thus detect changes in sets
of lines, or single lines.

3. Easy implementation: If a header line has been changed, a warning can be
displayed (e.g. display the line in red).

4. Support for mailing lists: If a mail list agent changes the To header,
and if To was protected by its own hashed subpacket, the mail client will
display that this field has been changed.

I think our draft still needs a lot of refinement, and we will be grateful
for comments from this list.

We have implemented a Java client as a proof-of-concept, and a thunderbird
implementation is underway.

[1] http://www.ietf.org/internet-drafts/draft-liao-smimeheaderprotect-00.txt

Greeting

Joerg
www.nds.rub.de

________________________________________
Von: Russ Housley [mailto:[email-masked]] 
Gesendet: Donnerstag, 11. Oktober 2007 18:13
An: [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: Re: Header Protection for S/MIME

I have not seen any discussion of this document on this list.  It is
proposing a very different approach to a problem that was discussed on this
mail list.  The current MSG specification includes a very different solution
to this problem.

Russ

spt

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 18 Oct 2007 22:31:24 -0700

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Blake Ramsdell
> Sent: Monday, October 15, 2007 7:28 PM
> To: Kemp, David P.
> Cc: [email-masked]

I think that there is a shortage here as with the current embedded message
draft in terms of guidance about what to do for changed headers.  A
statement to the user that "one or more of the following headers was
changed" is more confusing to the user than displaying two sets of headers
which might be the default behavior with the current documents.

> you merge the resulting headers" approach that is the current practice?

I do have some other issues with this document as it currently stands.

1.  As you pointed out this document does not really meet the stated
criteria of finding out what header was changed.  As in the DKIM world all
you know is that someone changed the headers in such as way that the
canonicalization algorithm did not ignore what the change was.

2.  It is not clear to me that just placing the data of the headers into the
attribute and providing some ways of canonicalizing the comparisons between
the actual header and the attribute header is a better approach.

3.  It is not clear to me that this approach is actually smaller than
placing the headers to be protected into the attribute directly.

All that being said, my preferred solution to this problem has always been
to place the headers to be protected into an attribute.  I have never been a
fan of the embedded message approach.

Jim

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 19 Oct 2007 09:28:13 -0400

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jim Schaad
>
> All that being said, my preferred solution to this problem has
> always been to place the headers to be protected into an attribute.
> I have never been a fan of the embedded message approach.
>

Well now that 3 alternatives are on the table, I prefer Jim's
approach because a header-protection-aware receiver can use
the correct header values rather than just generating a
"something is wrong" error.

Was this ever written up in an I-D that could be resurrected,
or if not, is anyone going to write one?

---

From: Jörg Schwenk <[email-masked]>
Date: Tue, 23 Oct 2007 14:23:18 +0200

Some ideas to the problems mentioned below:

- I think the final version of this draft should give clear recommendations
about how to group headers to be hashed, e.g. TO and CC should be grouped
together because both can be used to send signed SPAM, and DATE and SUBJECT
should be grouped together because they contain metainformation about the
message. Using more than one hashed subpaket can make things clearer, e.g. a
change in the FROM field can be handled differently by the client if this
change comes from a mailing list agent.

1.- 3. We could make comparisons more robust by strengthening the
canonicalization algorithms. E.g. we could only select the RFC 822 mail
address, without the nicknames. (However, the behavior of mail clients when
displaying the header lines must be taken into account.)

If we have found a good, robust canonicalization algorithm, from a practical
point of view it shouldn't be important if we embed the result of the
canonicalization directly in the attribute, or if we hash it before. 

Joerg 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Jim Schaad
Gesendet: Freitag, 19. Oktober 2007 07:31
An: 'Blake Ramsdell'
Cc: [email-masked]
Betreff: RE: Header Protection for S/MIME

...

...

Jim

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Oct 2007 14:49:43 -0700

Everyone: please read RFC 4871 before suggesting headers and 
canonicalization. The DKIM WG spend a long time thrashing on these 
issues, and the result came from being worn down, not clean crisp 
design. This is a minefield.