Re: [ietf-dkim] Use of DKIM signatures by mailing lists

On Jun 14, 2006, at 2:04 PM, Jim Fenton wrote:

> Actions by author/signer
>
> The author and signer of a message subject to application of a  
> third-party signature by a mailing list should not have to take any  
> special action for messages sent to mailing lists, other than to  
> ensure that Sender Signing Practices, if any, permit third-party  
> signatures.
The message author may also be subjected to third-party signatures by  
providers offering unrestricted outbound signing services.   
Conditions instantiated by email-domain owner policies to allow  
inclusion within mailing lists will also likely permit "third-party"  
originating services as well.  This additional consideration impacts  
some actions taken by lists.

> Actions by lists
> ...
> With DKIM, it is also possible to check for a valid signature on  
> messages from list participants that sign their messages.  The  
> determination that a signature should be required from a given  
> participant can be made based on the presence of a signature when a  
> subscription request is sent, or could be an option selected on a  
> subscriber web interface such as that provided by Mailman.  If an  
> unsigned message is received purporting to come from a subscriber  
> that asserts that their messages are signed, the message should be  
> rejected via an SNMP 5xx code, if possible, or should be ignored.
A subscriber may utilize a multitude of signing originating  
services.  Ignoring messages where an expected signing domain differs  
from that of the initial subscription may become problematic.  More  
than just signed/not-signed cases should be considered.  Ignoring  
exceptions would be unfriendly, especially as providers begin to  
introduce message signing.  There should not be a general presumption  
that an author's email-address is normally within the signing domain.

> The presence of DKIM signatures on subscription requests and other  
> administrative traffic can, in come cases, be used to simplify the  
> subscription process.  Mailing lists may eliminate the confirmation  
> step of the message subscription process when a valid DKIM  
> signature is present to validate the requesting address.  However,  
> this is only a small benefit.
Before considering a signature as confirmation, there should be some  
explicit indication by the signing domain that the purported author  
of the message has been validated.  This explicit indication could  
depend upon the 'i=' identity specifically including the local-part  
of this email-address.

> Mailing lists should not remove DKIM signatures on incoming messages.
While a mailing list should not remove DKIM signatures valid upon  
initial receipt, what additional protection is afforded by including  
a signature known to be invalid prior to being signed and re- 
introduced into the mail channel?  Recommending inclusion of  
signatures known to be invalid seems a questionable practice, as  
there would be less to differentiate a spoofed signature from one  
originally found valid.  By recommending removal of known invalid  
signatures when the MTA supports DKIM, a greater amount of  
information is conveyed by remaining, albeit now invalid, signatures.

> Because the verifier is free to use whatever methods it chooses to  
> try to verify signatures successfully, it isn't, in general,  
> possible to know whether an incoming signature will continue to  
> verify correctly.  However, since some mailing lists are  
> advertising-supported, and would not want the verifier to remove  
> the advertising content in order to make the message verify  
> correctly, some lists will remove incoming signatures anyway.
For similar reasons, it seems prudent to remove signatures found to  
be invalid upon receipt.  In general, removal of known false  
information should be the best practice for avoiding the application  
of unexpected policies that might block the message.

> Actions by verifiers and recipients
>
> When presented with a valid third-party signature, a verifier may  
> wish to determine the role of the signer.  If the List-Id header  
> field is present, the associated signature will have an identity  
> (i=) corresponding with that header field.
How would this be any different than depending upon the signing  
domain?  Both are generally invisible.  This would only seem to  
affect possible message annotation that displays the 'i=' identity.

> When presented with a third-party signature, it is important that  
> the verifier or recipient compare the signing address against a  
> list of known, reliable addresses.
This is a recommendation for applying reputation?  It seems this  
precondition or recommendation is unneeded, as this would be  
dependent upon how the message is annotated.  As a general criteria,  
no assurances by way of annotations should be applied to signed  
messages, unless the signing domain is considered trusted.  There is  
also the issue related to internationalization of the local-part.   
Unless the signing domain is trusted, assures an elimination of look- 
alike local-parts, and makes explicit assertions that the email- 
address within the signing domain has been validated, only then would  
any assurance annotation seem appropriate.

> Relying on association with the List-Id alone is insufficient,  
> since attackers could easily send messages on behalf of a  
> nonexistent mailing list at a disposable domain in an effort to  
> have the message recognized as coming from a mailing list.
This statement seems to support the concept of a precondition of  
trust rather than reputation accrual.  Negative reputation accrual is  
not fast enough to support a safe assurance based upon a DKIM signing  
domain.
-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html