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

From: Jim Fenton <[email-masked]>
Date: Wed, 14 Jun 2006 14:04:25 -0700

The text below is a short essay I wrote in response to some discussion 
in a Jabber session a month or so ago.  John Levine graciously agreed to
review it, but any errors are mine.

The intent here was to present some thinking on how and why DKIM might
be used by mailing lists.  It does not impact the -base specification
other than, hopefully, to show that what's in -base is sufficient for
mailing list usage.  Some of this might be appropriate for the "DKIM
Overview Document" when we get to it.

-Jim

Use of DKIM Signatures by Mailing Lists
June 14, 2006

DomainKeys Identified Mail (DKIM) provides the capability for a message to be 
signed by a party other than the author of a message or the author's 
representative.  This type of signature is known as a "third-party" signature.  
Third-party signatures are expected to be used widely by mailing lists, 
particularly those that modify messages in a manner that would cause an author's 
DKIM signature to break (become invalid).  Up to this point, little attention 
has been paid to the details of how this would work.

Security issues affecting mailing lists

There are three classes of security issues that involve mailing lists:

1. At subscription time, the mailing list wants to know whether a request is 
from a legitimate subscriber.  Forgery of subscription requests is common, and 
is typically dealt with by challenge/response mechanisms or manual (human) 
moderation.
2. When a message is posted, the list wants to know whether the message is 
legitimate.  Unauthorized submission of messages is common, and is typically 
handled by checking the From: address on incoming messages against a list or by 
manual moderation.  Message forgery is currently rare, although this could 
change as other mechanisms for forgery become more difficult.
3. When a list distributes a message, subscribers want to know whether mail is 
really from the list.  This determination is typically made by checking the 
List-ID:, Sender: or other header fields inserted by the list.  Forgery of list 
messages is currently very rare, but this could be expected to change if such 
forgeries are successful in getting messages accepted by recipients.

Potential benefits of DKIM to lists

DKIM signatures might be useful to mailing lists in the following ways:

1. DKIM should be useful to verify that a sender is who he says he is, or at 
least who he said he was when he subscribed, so messages with DKIM signatures 
from subscribers (or possibly others with good reputations) might be directly 
accepted, while others will face more scrutiny such as a callback or manual 
moderation.
2. DKIM should be useful to allow recipients to recognize list mail, in the same 
way as it would be used to recognize any other mail from a known correspondent.
3. For the small fraction of mailing list subscriptions initiated by mail (vs. 
via web sites), DKIM could help authenticate the sender and perhaps simplify the 
subscription process.

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.

Actions by lists

Just as they do today, mailing lists should do whatever they see fit to limit 
the distribution of undesired messages via the mailing list.  This may include 
checks to see that the From address on the message is a member of the list, 
active (human) moderation, or other measures.  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.

Messages should be signed by mailing lists using the identity of the list 
itself, as shown in the List-Id header field being added, if any. For example, 
if the List-Id is <ietf-dkim.mipassoc.org>, the signing identity (i= field of 
the signature) should be [email-masked].  This provides the most 
unambiguous interpretation of the role of the signer by the verifier.

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.

Mailing lists should not remove DKIM signatures on incoming messages.  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.

If a mailing list or other intermediary wishes to assert that a message verified 
correctly when received, it should apply a header field such as Authentication-
Results and include that header field in its outgoing signature.  The semantics 
of such an arrangement are unclear, because the recipient should consider any 
signed message from a known, trusted mailing list favorably, even without a 
signed incoming signature.

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.

The verifier or recipient may also act on the signing identity alone, since 
addresses used by mailing lists will usually assume no other role.

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.  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.

As with all third-party signed messages, it is helpful if the MUA is able to 
display the signing identity as well as the author's.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 14 Jun 2006 14:26:27 -0700

> Overview Document" when we get to it.

It might be worthwhile to define "mailing list" in the document -- all 
of us here on this mailing list surely must know what the term means, 
but the wider audience may assume it's about marketing and become 
extremely confused.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Wed, 14 Jun 2006 14:30:25 -0700

On Jun 14, 2006, at 2:26 PM, J.D. Falk wrote:

> It might be worthwhile to define "mailing list" in the document --  
> all of us here on this mailing list surely must know what the term  
> means, but the wider audience may assume it's about marketing and  
> become extremely confused.

Mailing-list is a very broad term. Some of this is applicable to
general mailing lists, but it seems that most of it was written
with "discussion lists" in mind. Defining "mailing list" to mean
the same thing as "discussion list" for this document might
increase confusion rather than reduce it.

Cheers,
   Steve

---

From: Jim Fenton <[email-masked]>
Date: Wed, 14 Jun 2006 14:52:07 -0700

> increase confusion rather than reduce it.
The intent is that "mailing list" means the same thing as it does in RFC
2919, although I don't see a clear definition of the term that would
satisfy J.D.'s concern there, either.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Jun 2006 14:55:23 -0700

> increase confusion rather than reduce it.

Is it me, or does anybody else get nervous about the possibility of
this being a very deep and ultimately unrewarding rathole? This is
all very BCP-like, and I'm not sure we even know what the BCPs
ought to be at this point, and most especially for mailing lists. I really
don't think that the base suggestion of lists signing as the Sender/Listid
is actually rocket science and I've actually seen mailing lists in the wild
DKIM signing now, so it's at least pretty obvious to some mailing list
owners.

One comment about the text though: I really don't think we need to be
straying into the profit motivations of mailing list owners. That sentence
should just be deleted.

       Mike

---

From: John Levine <[email-masked]>
Date: 14 Jun 2006 22:02:27 -0000

>increase confusion rather than reduce it.

I think that Jim and I both intended this discussion to cover discussion
lists, so how about pretending that it says discussion list wherever it
says mailing list?

For broadcast lists, I don't think there are any particular DKIM problems
since the content either comes from the sender or the sender is an agent
of the author.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Wed, 14 Jun 2006 15:09:50 -0700

> since the content either comes from the sender or the sender is an  

Yup. I'm more arguing against any definition of mailing list in the
document, really, especially one that contradicts one of the more
widely used usages. If you're in the intended audience then you'll
know it when you see it and any definition is not going to be useful
to you.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Jun 2006 16:13:47 -0700

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.

> 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.

> 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