ietf-mailsig
[Top] [All Lists]

Re: one more time: agreeing on the basic goal of MASS

2004-11-23 18:27:38

On Mon, 2004-11-22 at 22:13, John Levine wrote:
Even in the case of per user keys it is presumably the domain
providing those keys and thus the authorization though. Right?

Right.  If you don't like the mail, you complain to the domain, not to
the user, since the domain's the one who can change or revoke the key.

I agree with this sentiment, but the digital signature providing a means
for source authentication.  This authentication provides an accountable
entity.  This could be described as evidence of authorization to source
a message, but not directly as sender authorization.

Mail policy found within these schemes, as example, may constrain sender
authorization. Confusion of authorization and authentication was a
problem in the past.  It would seem appropriate to make each concept
explicit via the goals and not merged as if one.  Source authentication
and sender authorization describe separate steps with distinct
considerations. 

I find it helpful to remind people that the result of any
authentication scheme is only that you know who to blame for the
message, not whether a message is spam, or whether the the recipient
has a relationship with the sender, or anything else.  That's why
replay attacks are out of scope here, if I'm the responsible party for
a massage, I'm still the responsible party if a hostile recipient
remails it a thousand times.

Down the road when reputation systems are more mature it may be useful
to put assertion tags into signatures, e.g. "this is transactional
mail" or "this is unconfirmed opt-in bulk mail" a la TEOS.  It looks
to me that both of the major candidates (DK and IIM) have room for
more fields in the signature data so we have that option.

One may wish to also note lack of a signature removes sender
authorization, or that the authorization is only valid within specific
HELO domains as example. 

As sender authorization involves more complexity, limiting a goal to be
simply source authentication would seem to be the safe approach for the
first step.

Defining how a sender is authorized would be another longer term goal
that may involve methods of asserting policy as a subsequent step.

-Doug





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