Subject: [ietf-dkim] dkim-lists draft (was Re: Why mailing lists should strip DKIM signatures)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Jun 2010 00:59:41 -0700

The masochistic side of me spent some time going through this entire thread over the long weekend to fish out the pieces that can be folded into the lists draft.  This is a summary of that sifting, which I'm using to generate the -01 draft.

Please, folks, change the Subject: field for the ADSP-specific part of this discussion.  The part of the thread that has to do with what we can tell list participants and software developers now must be based on RFC4871 and RFC5617, and not on what we think either of those things should have been in the first place.  The rest is a totally different conversation, unless we think we need to fix those before any list practices get discussed, which I don't believe to be the case.

Also, please constrain follow-ups to this posting (with this Subject:) to the lists draft, and in particular, +1s, proposed changes to wording, or sections that should be added, rearranged or removed.  The more specific you are, the more useful the contribution; stuff like "you should say more/less about ADSP" isn't really meaningful.

In several places, where there have been suggestions to remove some text from the draft because it conveys a bad idea, I intend to leave it in accompanied by text explaining that it's a bad idea and why.  I believe it's better to close off such a path from a new participant than it is to leave it unexplored.

An interesting point came up late in the thread, and that is a challenge to our well-established mantra that the MUA is the slowest thing to change.  With Gmail and Yahoo being active-yet-silent participants in all this, and I think we can presume the likes of AOL is included, and even open source solutions like Horde might not be far behind, is that all still true?  If not, then perhaps the lists document might suggest some MUA improvements to assist with all of this effort.  Or maybe a separate effort can be started that recommends common MUA changes to make them more DKIM-aware and put some of all this work to better use.

Finally, a question: So that an MLM can proudly exclaim "We are RFCxxxx compliant!" and have it be meaningful, should this document seek the status of a BCP, or is Informational sufficient?

Now then:

> -----Original Message----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Friday, April 23, 2010 9:41 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Why mailing lists should strip DKIM signatures
> 
> [...]
> There's no new semantics, deep or othterwise.  Yahoo is treating the
> signature as an assertion of responsibility -- it has my signature,
> the recipient complained about it, they have reason to think I'm not
> evil, so they sent me the complaint.  All that is fine, but the
> problem is that for list mail, I'm not the one who can do anything
> about it.

I kind of don't buy this as a DKIM-specific problem.  Even before DKIM, a provider might decide to send a copy of the complaint report to you since you're in the From: even though there's a Sender: or the IP address matched an FBL registration or something.  It might be useless, sure.  But it's not a fault specifically of DKIM; it's a questionable FBL choice.

> If a list adds its own signature and leaves the contributor's, now
> it's up to heuristics by the recipient to guess what to do.  For list
> mail, the correct guess is to treat the list as responsible.  Wouldn't
> it be a better idea to avoid the guessing?

Again, pre-DKIM, that could still happen.

But in the DKIM world, the FBL could take this apparent heuristic one step further and identify the list's signature by matching it to other domains like the one in List-Post: or such, and thus not bother the author since, as you say, she/he can't do anything about it.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Friday, April 23, 2010 10:07 AM
> To: IETF-DKIM WG
> Subject: Re: [ietf-dkim] Why mailing lists should strip DKIM signatures
> 
> [...]
> >  Wouldn't
> > it be a better idea to avoid the guessing?
> 
> Yes, by notifying all the responsible parties who have set up a
> DKIM based FBL and who have valid DKIM signatures on the
> message.

+1 (and there were at least two other +1s)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ian Eiloart
> Sent: Wednesday, April 28, 2010 2:19 AM
> To: McDowell, Brett; [email-masked]
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
> 
> [...]
> 
> Mailman doesn't check DKIM signatures, or add them. Quite properly, in
> my
> opinion, this is regarded as the business of the local MTA, not the MLM
> software.

I find this a particularly important point to framing of the problem.  And this is in part exactly what RFC5451 was for.  Unfortunately to provide a lists BCP in general, we have to consider that some MLMs will be forced to do that work as their MTAs are not DKIM-aware, so we need to be general about this (i.e. say that verification should be done, but not specify which agent in the local chain does it).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of MH Michael Hammer (5304)
> Sent: Wednesday, April 28, 2010 8:03 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists should strip DKIM signatures
> 
> [...]
> 
> 2) One possible recommendation to list managers is that if a message to
> the list is DKIM signed AND has an ADSP discardable policy AND the
> signature cannot be maintained intact then the list should bounce the
> message.

We seem to have rough consensus on this point, and it's in the draft.

> 3) Is there a way for us (perhaps in a future version) to provide for
> some sort of "encapsulation" that will allow the original
> signature/message to be maintained even as the list does certain (as
> yet
> unspecified) actions which might currently break the signature? Just
> blue skying here.

Technically yes: The MLM could MIME-ify the original message as a message/rfc822 part in a larger message that contains anything else it cares to add -- headers, footers, new header fields, whatever -- and that encapsulated message could include its original author signature, which presumably would continue to validate if evaluated over that encapsulated message.  That would probably solve a lot of problems, although it's ironic that we'd be encouraging an even more substantial change to the message to get around the problem of messages being changed.

But as I recall, we have text in various places saying DKIM signatures inside MIME parts shouldn't be evaluated anyway.  Maybe that should be revisited given the possible value of it in this context.

> 4) I recognize the chorus which says "mail lists have always done
> things
> a certain way and who are you to tell us how or what we have to do".
> Having given that recognition, in creating an authentication model it
> seems self defeating not to provide mechanisms for the authentication
> to
> survive things like maillists (for those maillists/software providers
> willing to adopt whatever we come up with). Those lists which have
> always done thigns a certain way and wish to continue could do so - no
> harm no foul.

That would be ideal, but we've created an authentication mechanism that relies on MLMs not doing things they've been doing for a long time.  Maybe a mechanism like what you're describing could be concocted, but DKIM isn't it.  The best shot at this would be an alternate canonicalization, which has been proposed, that is more likely to survive the myriad modifications that are described in the lists draft (and others we may not have mentioned), but specifying, let alone implementing, such a thing would be a small nightmare.

I suspect if we want to design an authentication mechanism that is specifically transparent to lists, we need to start over.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ian Eiloart
> Sent: Tuesday, May 04, 2010 1:48 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion
> 
> [...]
> > I agree it's hypothetically possible, but have you ever seen an actual
> > need for this in practice, a list where the recipients filter out
> > messages that a more competently managed list would have rejected?
> 
> I've seen spam posted to mailing lists. Recently, I've seen lists
> targetted
> in more intelligent ways by spammers. For example, by using sender
> addresses in the domain of the list (quite a useful way of attacking
> academic lists, which tend to have lots of local users, but some non-
> local).

Though I've not witnessed this myself, I think it stands to become a more common attack vector if it is found to be even marginally successful, because it's free to try.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, May 18, 2010 5:55 AM
> To: John Levine
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Lists "BCP" draft available
> 
> [...]
> 
> > Yes, of course.  The signature means that this message really truly
> > came from the mailing list, as opposed to being a random piece of
> spam
> > that happened to resemble list mail.
> 
> +1. However, may I ask how does the verifier know which signature is
> the one that belongs to the list? I can think of
> 
> * look at the MAIL FROM domain, à la SPF (breaks forwarding),
> * have the list's domain in a white list (requires maintenance),
> * use some of the "List-*" fields (which one?)
> 
> Apparently, section 5.4 doesn't cover this point.

Quite right.  And at the risk of doing something drastic like tying "d=" to something else in the message, I suggest the latter.  (Dave suggested something like that, and it was +1'd at least once anyway.)

And with that, draft-kucherawy-dkim-lists-01 has been posted for your perusal and feedback.  This thread was enormous so it's possible I missed something.  If so, please do point it out.

-MSK

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Jun 2010 08:11:40 -0700

> Though I've not witnessed this myself, I think it stands to become a more common attack vector if it is found to be even marginally successful, because it's free to try.

I see list spam all the time on the android-developer list. Some of it seems
to be more targeted, some of it doesn't. I assume that googlegroups spam filters
its incoming mail just like anything else that's directly connected to the sewer,
so what I'm seeing is the remaining false negatives. So the notion that lists are
somehow immune is quaint and outdated. If there's a big enough audience, or it
targets something that spammers want, they'll apparently go to the effort of
either subscribing or spoofing or whatever to get their turds through.

Long and short: the link between originator and list is important and probably
will become more important for large lists as software automation lowers the
barriers. Email harvesting is probably by far the easiest thing because your
legit email address is sitting in the public archives. Using DKIM to predict
likely spoofs would be a good thing, especially since there's an ongoing relationship
between subscriber and list.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 01 Jun 2010 19:53:42 +0200

> Finally, a question: So that an MLM can proudly exclaim "We are RFCxxxx compliant!" and have it be meaningful, should this document seek the status of a BCP, or is Informational sufficient?

IMHO, a BCP is appealing, but more challenging. The draft already 
contains several explanation that are relevant independently of DKIM. 
Some of these, in particular section 3.2 (see below), should be 
improved so as to become generically acceptable. For a BCP, I would 
change the title to "Mailing Lists And DKIM", "Mailing Lists Using 
DKIM", or similar.

Perhaps, in case the I-D will provide a production rule for subject 
tags, it may be worth considering it a proposed standard.

> Now then:

I have a few points, ordered by section number. Don't be scared by the 
length, most text is quoted from the I-D, for readers convenience.

----- 1.1
The last paragraph in section 1.1 looks redundant to me.

  The DKIM specification documents deliberately refrain from the notion
  of tying the signing domain (the "d=" tag in a DKIM signature) to any
  identifier within a message; any ADMD could sign any message
  regardless of its origin or author domain.  As such, there is no
  specification of any additional value if the content of the "d=" tag
  in the DKIM signature and the value of (for example) the From header
  field match, nor is there any obvious degraded value to a signature
  where they do not match.  Since any DKIM signature is merely an
  assertion of "some" responsibility by an ADMD, a DKIM signature added
  by an MLM has no more, or less, meaning as a signature with any other
  "d=" value.

It looks redundant because the semantic intentions of DKIM are already 
discussed at length in the paragraphs about SDID, AUID and their 
relationships, in RFC 5672. The latter is currently not a normative 
reference; however, [DKIM] is: I'd be curious whether the "Updated by: 
5672" in [DKIM] formally makes RFC 5672 normative, as if explicitly 
referenced in the I-D.

At any rate, unless someone finds them helpful, I think those 
difficult considerations could be omitted, referencing RFC 5672 
instead. One difficulty is indeed the apparent contradiction with 
[ADSP], where it defines the binding with the exemplified "From" 
header field.

----- 3.2
In section 3.2, "Types Of Mailing Lists Lists" there is a possible 
typo in the title.

The first bullet reads:

  aliasing:  An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one
     that makes no changes to a message as it redistributes; any
     modifications are constrained to changes to the [SMTP] envelope
     recipient list (RCPT commands) only.  There are no changes to the
     message body at all and only [MAIL] trace header fields are added.
     The output of such an MLM is considered to be a continuation of
     the author's original message.  An example of such an MLM is a
     address that expands directly in the MTA, such as a list of local
     system administrators used for relaying operational or other
     internal-only messages.

I would the phrase "at all", because the MTA may modify the MIME 
layout of the message with no control by the MLM software. I'd mention 
this possibility in the next section ("Major body changes" below.)

The second bullet reads:

  resending:  A resending MLM (see Sections 5.2 and 5.3 of
     [EMAIL-ARCH]) is one that may make changes to a message.  The
     output of such an MLM is considered to be a new message; delivery
     of the original has been completed prior to distribution of the
     re-posted message.  Such messages are often re-formatted, such as
     with list-specific header fields or other properties, to
     facilitate discussion among list subscribers.

Section 5.2 of [EMAIL-ARCH] is for ReSender. Do we need it? In 
addition, I'd rename the bullet as something like "traditional" or 
"lists proper", that conveys that this is the main character. Finally 
for this bullet, section 3.9.2 of [SMTP] does not consider list 
messages to be "new messages" (more on this below.)

The third bullet reads:

  authoring:  An authoring MLM is one that creates the content being
    sent as well as initiating its transport, rather than basing it on
    one or more messages received earlier.  This is a special case of
    the MLM paradigm, one which generates its own content and does not
    act as an intermediary.  Typically replies are not generated, or
    if they are, they go to a specific recipient and not back to the
    list's full set of recipients.  Examples include newsletters and
    bulk marketing mail.

As it actually describes several types, it may be more meaningful to 
make it the last one. Newsletters and such can also be implemented as 
announce-only mailing lists --only subscription policies differ ;-)

For completeness, I also quote the fourth bullet:

  digesting:  A special case of the re-posting MLM is one that sends a
     single message comprising an aggregation of recent MLM submissons,
     which might be a message of [MIME] type "multipart/digest" (see
     [MIME-TYPES]).  This is obviously a new message but it may contain
     a sequence of original messages that may themselves have been
     DKIM-signed.

If going for BCP or PS, I'd put a subsection-break after these 
definitions.

The following paragraph could be reworded, avoiding unnecessary 
assumptions, from

  The remainder of this document operates on the presumption that a
  message going through a resending MLM actually comprises two message
  transactions:

to

  In the remainder of this document we distinguish two relevant steps,
  corresponding to the following [SMTP] message transactions:

Furthermore, I'd name the message content of those two steps, e.g. by 
tagging rather than numbering the relevant paragraphs, with names like 
"MLM-input" and "MLM-output", so as to make references to them precise.

Now for the last paragraph in section 3.2:

  The dissection of the overall MLM operation into these two distinct
  steps allows the DKIM-specific issues with respect to MLMs to be
  isolated and handled in a logical way.  The main issue is that the
  repackaging and reposting of a message by an MLM is actually the
  construction of a completely new message, and as such the MLM is
  introducing new content into the email ecosystem, consuming the
  author's copy of the message and creating its own.  When considered
  in this way, the dual role of the MLM and its ADMD becomes clear.

I tend to associate "new message" to a new Message-ID. Only the last 
two types actually do that. I think you mean that a MLM reinjects the 
/same/ content into a different "message stream". The latter concept 
is also used in RFC 5863, which omits a formal definition, though.

----- 3.4
The last paragraph in section 3.4 reads:

  A possible mitigation to this incompatibility is use of the "l=" tag
  to bound the portion of the body covered by the body hash, but this
  not workable for [MIME] messages and moreover has security
  considerations (see Section 3.5 of [DKIM]).  Its use is therefore
  discouraged.

I would omit the last sentence. In facts, the warning in section 3.5 
of [DKIM] says that "l=" has been designed exactly for this purpose. 
Discouraging it, is a withdrawal of that statement.

----- 4.2
The last paragraph of section 4.2 reads:

  Note that the underlying problem is the operational choice to use
  ADSP in a message stream that does not maintain the signature.

The verb "use" is correct for subscribers, "allow" for MLMs. I'd 
s/use/allow or use/, since the I-D is not specifically targeted to 
subscribers. I'd also make explicit that _one_ subscriber using ADSP 
results in _all_ subscribers having to whitelist the MLM sender.

----- 5.1
I agree with sending the ADSP-warning. Readers should be advised that 
"dkim=discard" may be set at any time after subscription, though.

----- 5.4
Bullet 1, at the beginning of section 5.4, says

  1.  Attempt verification of all DKIM signatures present on the
      message;

That is an operation that a MLM may want to do again after modifying 
the message, in order to check whether any signature has been broken. 
I'd add "MLM-input" to that bullet, to improve clarity.

> We seem to have rough consensus on this point, and it's in the draft.

Not quite: the last paragraph in section 5.4 says

                               It is the consensus of the working group
  that a resending MLM is advised to reject outright any mail from an
  author whose domain posts such a policy as it is likely to be
  rejected by any ADSP-aware recipients, and might also be well advised
  to present a warning to such subscribers when first signing up to the
  list.

Mike didn't mention likelihoods. His text, quoted above, makes a more 
precise point.

----- 5.5
The second paragragraph in section 5.5 reads:

  A signing MLM is advised to add a List-Post: header field (see
  [LIST-URLS]) using a DNS domain matching what will be used in the
  "d=" tag of the DKIM signature it will add to the new message.  This
  could be used by verifiers or receivers to identify the DKIM
  signature that was added by the MLM.

Partly agreed. Although it may not be available for "authoring" lists, 
List-Post is less ambiguous than List-ID, since it makes explicit 
which is the local part. But why not use the whole local part ("i=")? 
What if an author has a mailbox within the same domain? Although 
header.b allows to distinguish them, how does one know which one is 
the MLM signature, or that there is a MLM signature at all?

In case we care about the role of the signer, we need a precise 
recipe. By comparison, in real life we often have it: e.g. "Treasurer 
of the United States" on a dollar bill would not be exactly the same 
as "X-Been-There", would it?

Would it make sense to define the subject tag in terms of the local 
part in List-Post? (That is, subject-tag = "[" local-part "]".)

Now for the paragraph after the bullets. It says

  A DKIM-aware resending MLM is encouraged to sign the entire message
  as it arrived, especially including the original signatures.

The "as it arrived" part is unclear to me, and I'd suggest using 
MLM-input/MLM-output as appropriate.

----- 5.7
Section 5.7, Use With FBLs.

I like this a lot, bravo!! To clarify it even further, I'd add a note 
mentioning that controlling FBL routes is one of the reasons to remove 
author signatures. It may shred additional light to mention that it is 
up the MLM's domain to define FBLs policies. As long as subscribers 
are informed about what happens when they hit that button, anything is 
cool. For example, one list may equate complaints to unsubscribe 
requests, while another one may use them for reporting OT messages.

----- 5.8
The second paragraph,

  Receivers are advised to ignore all unsigned Authentication-Results
  header fields.

is obviously formally wrong. (Actually, requiring to validate a 
signature in order to use the A-R field defeats its own purpose, but 
this is OT here.) I agree with John on this point, that determining 
the prior validity of an author signature at this stage is only 
relevant for forensic analysis and similar tasks. I'd omit that 
paragraph tout-court, as it is hard to explain to someone who hasn't 
read [AUTH-RESULTS], and useless otherwise.

The last paragraph I'm commenting is the next:

  Upon DKIM and ADSP evaluation, a receiver may decide to reject a
  message during an SMTP session.  If this is done, use of [ENHANCED]
  is advised to make a distinction between messages rejected
  deliberately due to policy decisions rather than those rejected
  because of other deliverability issues.  In particular, a policy
  rejection is advised to be relayed using a 5.7.1 enhanced status
  code, in contrast to a code of 5.1.1 indicating the user does not
  exist.  Those MLMs that attempt to automatically remove users with
  prolonged delivery problems (such as account deletion) will thus be
  able to tell the difference between policy rejection and delivery
  failures, and act accordingly.  Where the receiver's MTA does not
  support enhanced status codes, [SMTP] reply codes could also be
  carefully selected (554 and 550, respectively, for example).

I've already written on its merit in 
http://mipassoc.org/pipermail/ietf-dkim/2010q2/013561.html so I limit 
this comment to the reply definition. First of all, it is yet another 
reason for BCP/PS rather than informative: We are actually augmenting 
ADSP here, and the I-D deserves an updates="5617" attribute for this.

The definitions of the meanings of SMTP reply codes should be given 
independently of the advice on what MLMs can do with them, possibly in 
their own subsection. I'd mention [SMTP] codes before [ENHANCED] ones. 
Registering the enhanced status code will affect section 6. Requiring 
a substring match at the beginning of the human-readable part of the 
reply, e.g. "ADSP failure", at least for servers advertising no 
ENHANCEDSTATUSCODES, may increase robustness.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 01 Jun 2010 20:53:26 +0100

On Tue, 01 Jun 2010 08:59:41 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

> Please, folks, change the Subject: field for the ADSP-specific part of  
> this discussion.

OK, that old thread had gotten very ragged.

Unfortunately, I got around to reading your draft only recently, so I seem  
to have missed your deadline :-( .

My main comment is in relation to whether the old, failing, DKIM signature  
should be removed or not. You gave an example of where it was removed, but  
none where it was retained, and no real arguments pro or con either.

So here is my case for why it should be retained. (I think we agree that  
if the list has not actually broken the original signature, then it is  
best left even if the MLM provides an additional one).

Suppose the MLM changes the signature so as to break the Old signature,  
and provides an A-R header to say it was OK as received, and provides a  
New signature including the A-R. That much seems agreed as Good Practice.

Now suppose he leaves the Old signature intact. Will subsequent agents be  
confused? Not if they follow the standards, because an unverifiable  
signature is SUPPOSED to be treated the same as an absent signature (which  
is the other possibility under consideration). So, on that basis, any  
compliant verification agent SHOULD act the same whether is sees a broken  
Old Sigbature on no Old signature at all. (i.e. it should discard in both  
cases, or else try to make sense of the New signature, plus any List-*  
headers that may be around.

1. So the only downside of leaving the Old signature should be where an  
over-eager verifier tries to be clever and to treat failed signatures  
differently from absent ones - and for sure there will be such  
non-compliant verifiers around whether we like it or not.

2. OTOH, the is an upside in leaving the Old signature, insofar as it may  
help diagnose what has been going wrong (or whatever). Moreover some smart  
verifier that really wanted to be helful to its list readers (most likely  
one attached to the recipients MUA)  might even try to reverse engineer  
the changes made by the MLM, and recheck the signature (which, for a  
particular list recognized by the recipient or his MUA might actually be  
quite straightforward).

So we have to balance the problems introduced by would-be-smart verifiers  
that were non-standard compliant against other would-be-smart verifiers  
that might be able to use it. It is not obvious to me which way that  
balance goes, except to observe that is is usually NOT a good idea to  
destroy information that might be useful to someone.

Having said all that, I have a new proposal to solve this problem, which  
is that MLMs should actually change the From header. I think this has  
possibilities, but I have not had time to work out the details yet, so  
please Watch This Space!

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html