Subject: sender-auth and ira

From: "Housley, Russ" <[email-masked]>
Date: Thu, 25 Oct 2001 10:04:56 -0400

S/MIME WG:

Two I-Ds were posted, and I have not seen a single comment on them.  I hope 
this message starts a dialogue.

The two I-Ds are:
	draft-ietf-smime-sender-auth-00.txt
	draft-ietf-smime-ira-00.txt

The first one describes a problem, and the second one defines a solution 
for this problem.  I would expect the first one to be published an 
Informational RFC and the second to be published as a Standards Track RFC.

Russ

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 25 Oct 2001 09:36:11 -0700

At 10:04 AM -0400 10/25/01, Housley, Russ wrote:
>Two I-Ds were posted, and I have not seen a single comment on them. 
>I hope this message starts a dialogue.

Success. :-)

>The first one describes a problem, and the second one defines a 
>solution for this problem.  I would expect the first one to be 
>published an Informational RFC and the second to be published as a 
>Standards Track RFC.

The first draft (sender-auth) defines the problem with a lot of 
hyperbole. The second draft (ira) defines the problem much better. I 
would object to the first draft being moved even to Informational 
status unless:

- it was significantly shortened

- more emphasis was put on how to avoid the problem without protocol 
changes ("If Alice puts Bob's name in the first line of the 
message..." and "If the purchase order has the intended recipient's 
name in it")

- it is stated that the damage that is done by the recipient's 
carelessness is mostly theoretical and cannot happen when there is 
intended addressing information in the content

The solution in the ira draft is much better than the solution in the 
sender-auth draft in that it applies to things other than RFC 2822 
messages. It seems likely that the sender-auth proposal will become 
non-interoperable when there are many RFC 2822 headers with 
recipients in them (such as two To: headers) and with things like 
header folding. I think the ira draft stands on its own with the 
problem description and solution.

Both drafts would be a lot clearer if they said "sign then encrypt" 
instead of "sign and encrypt". The word "and" does not mean "then" in 
most languages, and doesn't necessarily mean it in English.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 25 Oct 2001 19:30:57 -0700

Russ,

I was hoping that this issue was going to disappear if I ignored it.  I
feel that the problem listed, while potentially interesting, is not one
that can be solved via this type of mechanism.

The problem:  I get a message, signed, and I forward it to you signed
and then possibly encrypted.  You believe that since it was encrypted to
you that nobody else could have sent it but the signer.

Response:  1) A better answer is to put names in e-mail.  2) Am I
suppose to start doing this for all signed mail.  3) How do I convince a
large company like Microsoft that this is even an interesting problem
for them to "fix" in their mail.  4) This does not fix information leaks
in anyway. (A far more interesting problem in my estimation.)

Why this does not work:  I don't know how to begin to tell Microsoft how
to write this code.  The simple case is, if my mail box name is not on
the To/CC line then pop up a warning message.  But this is not an easy
thing to say and program in.  

1. When I was working at Microsoft, people sent me mail at the address
"[email-masked]", my mailbox name was
"[email-masked]".  There is no way to determine that these
are or are not the same address.  While in this case they were they
could just have easily been different addresses.

2. Today, the email address that I give people is "[email-masked]",
but this is not the mail box address that I use.  This address forwards
mail to a second address where I down-load my mail from.  Now either the
message is always going to show up for me, or I have a configuration
issue to explain to users (and to write UI for).

3. If I receive e-mail because I am on a mailing list (such as this
mailing list), either I get the message for all mail to that list, or I
have a configureation issue to explain to users (and to write UI for).
This becomes even more fun if you look at nested mailing lists.  This
mailing list address could be contained on one or more other ietf
mailling lists thus I get mail indirectly and infrequently from some
other entity mailing list that I do not know that I am on.

4. BCC addressing causes massive problems.  Either the message always
comes up, I lose the concept of BCC because the address is included, or
a separate signature operation must be included for every BCC
recipeient.  (Does the BCC signature still have the list of all non-BCC
recipients?).  The process of generating addition signature operations
is not acceptable in my estimation, and would likely generate lots of
interesting problems with signed receipts.

5. What are the correct processing rules to deal with the following
situations:
- Nested signatures:  Does this element in an outer signature remove the
requirement for it to be checked on an inner signature?  Does it add or
change the behavior in some way?
- Parallel signature:  What does this mean for two different
side-by-side signatures, possible with different recipient lists?  If I
am on either list I don't need to display this warning?
- Nested Messages:  What happens if I bodily encapsulate an RFC822
message and forward it to you.  Do you check for the encapsulating but
not the embedded message?  Do you check the embedded message for the
from address of the encapsulating message?

I think that this is an interesting accademic problem, until I see a
real world need for a solution I think it should be ignored.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Housley, Russ
> Sent: Thursday, October 25, 2001 7:05 AM
> To: [email-masked]
> Subject: sender-auth and ira
> 
> 
> 
> S/MIME WG:
>