Re: [ietf-dkim] Re: DKIM and mailing lists

On Jan 19, 2006, at 1:57 AM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > Modifying the message is already a common practice by list-servers  
> > and resigning a modified message may not overcome restrictions  
> > imposed by a From email-address policy.
> Then it's not more the original message, they could send it as  
> "digest" (multipart/digest, a single message/rfc822, or maybe some  
> kind of application/mbox) or resend it with their own Resent-*  
> header fields, above all with their own Resent-Message-ID.
> Substantially different messages need different Message-IDs,  
> otherwise it breaks horribly (e.g. in mail2news scenarios).
The list-server would be one example of where mediators normally  
utilize the email-address of the initial author.  For many  
recipients, this is what they expect to see.  While some view this as  
an attempted forgery, many legitimate services will have a different  
view.  You could be right about encapsulating messages, but that  
represents a fair amount of change.  This may produce ugly text for  
some MUAs, and may break the reply mechanism.  One of the reasons for  
implementing DKIM was to maintain transparent security, but to handle  
this clumsy and broken SSP From restriction, DKIM becomes far from  
remaining transparent.
Adding a role to the signature would allow the source of From headers  
to be treated differently.  From a security aspect and a replay  
concern, the message should have the incoming signature removed and  
replaced by an MDA signature, where the role of the signature is also  
important.  When the message is submitted, any MDA signature must be  
removed and the MSA or mediator signature would be added.  When the  
recipients are defined by the initial sender, both the MSA and  
mediator signatures could appear when the message has not changed.   
When the message is changed, the MSA signature should be obfuscated  
by a "!Verified"/"!Invalid"/"!Unknown" statement that indicates  
whether it had been verified or not and included within the mediator  
signature.
There is no reason why separate assertions can not be made with  
respect to whether a mediator is permitted to remain transparent.  It  
is a major error in judgement to base security upon what the  
recipient _may_ see.  A recognition scheme could easily handle MSA/ 
MUA signatures differently from those of mediators, and ensure only  
those messages registered using an initial "out-of-band" method of  
identification are highlighted or marked.
This binding approach replaces the third-party trusted-certificate  
scheme that Phillip suggests, where even when a certificate is  
trusted, there is still no assurance what the user sees.  Registering  
the source of the message by the recipient offers perhaps the only  
safe method where messages can be highlighted or marked in some  
manner that could be safely communicated to the recipient.  Commerce  
sites getting phished only need to add a DKIM signature.  Filters  
will need to look at much more than the From header to abate phishing  
scheme.  SSP offers little _if any_ additional protection.  Any  
indication a message conforms to some SSP requirement will only serve  
the interests of the bad actors.

> > Adding a signing role avoids difficulties in classifying the  
> > nature of the source
> There's no need to sign a message that is already signed as long as  
> it's still the same message.  If it's some kind of "derived  
> message" see above.  For the clumsy Resent-* cases they could  
> remove the old signature.  Or we could offer some Resent-DKIM  
> header field.  Or "we" decree that Resent-* is "out of scope" for  
> all kinds of DKIM-signatures.
> > > > It may also require that the From email-address be moved  
> > > > entirely into the body of the message and replaced with the  
> > > > email-address of the mailing-list.
> > > NAK.
> > This would be a follow-on of the closed policy issue when dealing  
> > with message changes.
> If what you're talking about is the "use digest or Resent-* for  
> modified messages" case, then the old From could be in fact moved  
> into a complete message/rfc822 part (for digests).
I guess the question that would then need to be raised, would this  
digested message approach fly.  This approach makes OpenPGP and S/ 
MIME look more attractive.

-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org