Re: [ietf-dkim] Not exactly not a threat analysis

> > Look, it's not acceptable for DKIM to change the semantics of From.
> > From can contain multiple addresses, From can contain an address other
> > than that of the Originator, and if a Sender field is present From has
> > no implied relationship with the party that originated the message.
> > These semantics are well-established and have been in use for around 25
> > years.
> >  
> SSP as currently written does use Sender: (as a tie-breaker) in the 
> event that From: has multiple addresses.  An alternative way to do this 
> might be to do an SSP for each address in the From: field that doesn't 
> have a valid signature (modulo disagreement on this point) and use the 
> most restrictive policy found.
Sender is so widely misused in practice that you really need to define a 
new field for this, or better yet, just define a new one that has 
cleaner semantics.  In particular, a message can get "sent" more than 
once, so you need to have the possibility of having multiple senders and 
indicating the order.
The point is that, for a variety of reasons, From really has no implied 
relationship with who sent the message, and has only a tenuous 
relationship with who wrote the message.   People have stood on their 
heads trying to reconcile this with the desire to make the IDs of 
principals who sign the message agree with the legacy message headers, 
but it just doesn't fit - there are too many different things that are 
done with messages, for justifiable reasons, that invalidate this 
assumption.  Rather than try to change the way that existing fields are 
used, it makes a lot more sense to just define new fields (or parameters 
within a DKIM-Signature field) that have the semantics you want.
> > If you want to define a way for DKIM to say "the party who sent this
> > message has permission to make statements on behalf of these From
> > addresses" that's all well and good.  What's not appropriate is to
> > define DKIM in such a way as to wire in an assumption that From is
> > always the party who originated the message.
> >  
> We need to balance here between the definitions in specifications and 
> how ordinary people look at email.SSP is based on From: because that's
> almost always what people see and if you send someone a message, and ask 
> who it's from, they will almost always point to it.  If the recipient 
> thinks that From is the party who originated the message, that's 
> significant.
I'm all for having DKIM be as easily understood by "ordinary people" as 
possible.  But trying to add new functionality to an existing user 
interface, without changing that interface, just doesn't work.  If you 
want DKIM to add value for recipients, MUAs need to display signed 
messages differently than unsigned messages anyway.  It might as well 
display the identity of the signer instead of, or in addition to, the 
From address.
Just as a proof of concept, imagine that MUAs started displaying DKIM 
signed messages differently than unsigned messages: unsigned messages 
would display From:, while messages signed by their authors would 
display something like Signed-From:  e.g.:
a) From header a(_at_)b(_dot_)c; signed by a(_at_)b(_dot_)c would be displayed:

        Signed-From: a(_at_)b(_dot_)c

b) From header a(_at_)b(_dot_)c, b(_at_)b(_dot_)c; signed by a(_at_)b(_dot_)c 
would be displayed:

        Signed-From: a(_at_)b(_dot_)c [[claiming to represent a(_at_)b(_dot_)c, 
b(_at_)b(_dot_)c ]]

(presuming that the From header were included in the signature)

c) From header a(_at_)b(_dot_)c; no signature would be displayed:

        From: a(_at_)b(_dot_)c

The point is that the user interface needs to change anyway so that 
users will be aware of DKIM, and if it changes, there's no particular 
need to depend on existing users' expectations about the semantics of 
the From field.  They'll learn to understand the new indications. 
(however we would want to try to have this displayed with reasonable 
consistency across different user agents)
Keith
_______________________________________________
ietf-dkim mailing list
http://dkim.org