ietf-mailsig
[Top] [All Lists]

Re: Sender signatures are useful for...?

2004-12-09 23:49:14

On Thu, 2004-12-09 at 19:35, wayne wrote:
In 
<1102627153(_dot_)2880(_dot_)170(_dot_)camel(_at_)localhost(_dot_)localdomain>
 Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:

On Thu, 2004-12-09 at 11:50, wayne wrote:
In <16824(_dot_)40492(_dot_)723484(_dot_)512812(_at_)mtcc(_dot_)com> 
Michael Thomas <mike(_at_)mtcc(_dot_)com> writes:

So it seems that a lot of people are taking it as axiomatic
that a Sender: signature provides some utility.

Personally, I see very little utility in protecting the Sender:
header, and far far less in protecting the Resent-* headers.  I see a
lot of utility in protecting the From: header, the envelope from
(2821.MAILFROM), and the HELO domain.

How does this get deployed?  The From is a function of the Originator
and can be a domain independent of the Submitter domain.

I'm not curtain what you are asking.  I may have not been clear in
what I was stating.  I don't think a *single* system has to protect
the 2822.From:, the 2821.MAILFROM and the 2821.HELO, those are just
the identities that I see as being most useful to protect with various
systems.

While it may be useful to validate the Originator, a simple and
manageable system will likely rely upon the Submitter signing the
message.  Unless the Originator is within the Submitter domain, which
could be the case, the Sender header (which can be supplanted by From
when From and Sender are the same) is the most likely reference for
signature validation.  

Most of the systems talked about on this MASS list deal with the 2822
identities, but the signatures in SRS and SES also can protect the
2821.MAILFROM (via callbacks).  I don't know of any signature system
that protects the 2821.HELO.
 
It would be hard to see how HELO would benefit from a signature, while
it could offer a larger structure to support a signature than possible
with MAILFROM.  The best scheme for HELO appears to be CSV.  The best
scheme for MAILFROM appears to be BATV private signing.  These fields
are being handled in the CLEAR wg.

http://www.mipassoc.org/clear/

<snip>
The problem I see with trying to sign the Sender: and Resent-* headers
is that they are not always displayed by the MUA.  Even when they are
displayed, I suspect phishers can make effective use of implying that
the email is really from the phished company while signing the other
headers.

Sadly, a major MUA vendor tends to display just the pretty name for the
From field, so even From is not reliably displayed.  It appears
something is required in this area however. : (

If one were to imagine that the From domain (independent of the
Submitter domain) where used to sign the message, how would that be
done?  Would the private keys be distributed to the MUAs?  Would each
user have their own private key?  Would these keys be distributed using
LDAP?  How much traffic would be generated verifying the status of each
user key?  The signing of a message already exists in this manner, but
why is this not used?

Why is Sender (Submitter) a good choice for rapid and simple deployment?

The Sender (Submitter) must guard the private keys used to sign the
message.  The Sender (Submitter) already authenticates users with a
variety of existing methods.  If there is a problem, the Sender
(Submitter) is in the best position to resolve an issue quickly.  Using
the Sender (Submitter) model, there is much less risk, management, and
overhead, as there are far fewer keys and private keys are not
distributed.

-Doug


<Prev in Thread] Current Thread [Next in Thread>