Subject: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line

From: Franck Martin <[email-masked]>
Date: Thu, 31 Mar 2011 14:16:33 +1200 (FJT)

Silly question (?): 

Knowing that many mailing lists add [topic] at the beginning of the Subject line, what if DKIM was set to ignore that part when signing/verifying? 

Would it help to solve the problem of broken signature thru mailing lists? 

I realize the issue would be to also detect the add footer, but if I recall you can specify in dkim to sign only a certain length of the body and not the whole body. 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2011 00:05:03 -0400

> Silly question (?):

I was going to write a long rant, but I'll just say, you're right, it was 
a silly question.

R's,
John

PS: If you believe that you have a problem that would be solved if you 
could check slightly more of the submitters' signatures on list mail, 
there's nothing stopping you from writing a mutant DKIM checker that 
applies heuristics to the subject line or other parts of a message to try 
and guess what might have changed and reconstruct the message that was 
signed.  I think that Mike Thomas said he did something like that.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Mark Delany" <[email-masked]>
Date: 30 Mar 2011 20:19:42 -0700

> Would it help to solve the problem of broken signature thru mailing lists? 

In part. What you are doing is indirectly addressing mailing list
canonicalization. If I may be so bold, I think the Cisco innovation of
l= does much the same for another aspect of list mail.

But maybe this piecemeal/generalized approach to mailing lists is not
the right way? For example, is l= really useful outside of lists? Is
your [] solution useful outside of lists?

Instead, what if we invented a canonicalization specifically for lists
that recognized the content munging of lists as first-class behavior
that encompassed things like l= and [] and other typical list munging?

If your "Silly question" suggests a list canonicalization, then, IMO,
it's a pretty interesting idea.

Mark.

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2011 00:33:23 -0400

> that encompassed things like l= and [] and other typical list munging?

How about if we just encouraged people who run lists to sign their mail?

This whole list signature breakage argument is a tempest looking for a 
teapot.  I sort my list mail by the list, not by the individual list 
contributors, and I've never met anyone who does otherwise.  After 
scratching my head for a long time, the only problem I can imagine that 
might be solved by preserving incoming signatures is a list with an 
incompetent manager who allows vast amounts of bogus stuff through his 
list, but for some reason people want to subscribe to it anyway and do the 
spam filtering that the list mangager should be doing.

Should such a list exist, the right thing to do is to fix the list, not to 
invent piles of arcane hackery so that subscribers can sort of reverse 
engineer what the list should have been doing all along.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

PS: Also consider that Yahoo Groups probably pumps out more list mail than 
all the Mailman and majordomo lists in the world combined, and there's no 
way we'd ever be able to back out the message rewriting that it does. 
Even Mailman does MIME rewriting when it adds footers that nothing like l= 
could work around.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 31 Mar 2011 00:08:51 -0700

I don’t think it’s a silly question.  In fact I recently approached the Mailman people to explore this question from their perspective.

It may be interesting or even somewhat useful to set up a new header canonicalization that tolerates this kind of thing for lists, but the real problem is that, statistically speaking, a list that adds a mnemonic to a Subject: field in the way you’re discussing usually also does other things to the list that will change the body.  The MLM draft we have approaching WGLC talks about several of these.  It would be pretty complicated to construct a canonicalization that anticipates all or even most of those.

Thus, fixing the mnemonic issue will only avoid a small number of broken signatures overall.

I think a more interesting idea would be to use DOSETA to sign the MIME parts instead of or in addition to the whole message.  I’m starting to plan out an implementation and will be looking for a couple of other sites interested in conducting some experiments.

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Franck Martin
Sent: Wednesday, March 30, 2011 7:17 PM
To: [email-masked]
Subject: [ietf-dkim] If DKIM would ignore [] at the beginning of the subject line

Silly question (?):

---

From: Barry Leiba <[email-masked]>
Date: Thu, 31 Mar 2011 04:15:17 -0400

> Knowing that many mailing lists add [topic] at the beginning of the Subject
> line, what if DKIM was set to ignore that part when signing/verifying?

Apart from what's been said:
We did discuss this, long ago.  Suppose a spammer used that to replay
signed list messages, changing this:

  Subject: [ietf-dkim] Re: Important DKIM issues

to this:

  Subject: [http://buy.my.stuff/$$$] Re: Important DKIM issues

?  You can apply more heuristics (limit the number of characters,
forbid URLs, etc), but the bottom line is that the whole thing's too
problematic to codify and recommend.  It's one thing to use these
sorts of heuristics in a private implementation, or for debugging
purposes.  It's quite another to standardize them and treat them as
first-class features.

> http://ph0rmaceutica1s-cheap.net/purchase.html

Barry, as participant

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 31 Mar 2011 10:37:57 +0200

On 3/31/2011 9:08 AM, Murray S. Kucherawy wrote:
> I don’t think it’s a silly question.  In fact I recently approached the Mailman
> people to explore this question from their perspective.
>
> It may be interesting or even somewhat useful to set up a new header
> canonicalization that tolerates this kind of thing for lists, but the real
> problem is that, statistically speaking, a list that adds a mnemonic to a
> Subject: field in the way you’re discussing usually also does other things to
> the list that will change the body.  The MLM draft we have approaching WGLC
> talks about several of these.  It would be pretty complicated to construct a
> canonicalization that anticipates all or even most of those.

To add to this for folks:  Murray and I have in fact been considering developing 
an added canonicalization scheme that is relatively more robust against a 
broader set of things that cause breakage.  His OpenDKIM has been developing 
some data about a set.  The list behaviors are part of that.

We haven't gotten into the technical detail yet.

> I think a more interesting idea would be to use DOSETA to sign the MIME parts
> instead of or in addition to the whole message.  I’m starting to plan out an
> implementation and will be looking for a couple of other sites interested in
> conducting some experiments.

While I also think that's interesting to explore, I'm not so enamored of it yet, 
largely because I see it as likely to be too messy to be practical at scale. 
But that's just intuition.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 31 Mar 2011 10:45:24 +0000

> Knowing that many mailing lists add [topic] at the beginning of the Subject line, what if DKIM was set to ignore that part when signing/verifying?

That's an implementation issue for verifiers, isn't it? If an rfc were to say anything at all, it might say that mailing lists will often break header signatures by prefixing the subject line. If a verifier finds a [] prefix and broken signature, it might like to try verifying a signature formed without that part of the subject line. It might also want to limit the number of characters in the prefix. And, it might like to keep a track of prefixes used with specific List-ID headers, to spot attempts to abuse this flexibility.

I suppose some guidance as to what might be acceptable in the prefix might be warranted. You could, for example, restrict it to substrings of the (also signed) List-ID header. That would severely limit replay attacks.  

Anyway, the list should be signing messages after adding subject line prefixes, and after adding body footers. It's the list's signature, and the list's reputation that need to be assessed by the recipient. There are many other modifications that a list might make (like stripping attachments, body prefixes, and so on) that would make l= useless.

-- 
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 31 Mar 2011 04:58:32 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ian Eiloart
> Sent: Thursday, March 31, 2011 3:45 AM
> To: Franck Martin
> Cc: <[email-masked]>
> Subject: Re: [ietf-dkim] If DKIM would ignore [] at the beginning of
> the subject line
> 
> That's an implementation issue for verifiers, isn't it? If an rfc were
> to say anything at all, it might say that mailing lists will often
> break header signatures by prefixing the subject line. If a verifier
> finds a [] prefix and broken signature, it might like to try verifying
> a signature formed without that part of the subject line. It might also
> want to limit the number of characters in the prefix. And, it might
> like to keep a track of prefixes used with specific List-ID headers, to
> spot attempts to abuse this flexibility.

There was pretty solid consensus against doing things like this in the past.  There was similarly solid consensus against trying to verify a signature using the "z=" header fields if they're present.

I believe we decided an implementation does so outside of DKIM's scope, and at its own peril; DKIM has to return a failure, but what you do after that is up to you.

> I suppose some guidance as to what might be acceptable in the prefix
> might be warranted. You could, for example, restrict it to substrings
> of the (also signed) List-ID header. That would severely limit replay
> attacks.

That's also something we considered when talking to the Mailman people.  But again, this is really a small percentage of what causes author signatures on list mail to break.

> Anyway, the list should be signing messages after adding subject line
> prefixes, and after adding body footers. It's the list's signature, and
> the list's reputation that need to be assessed by the recipient. There
> are many other modifications that a list might make (like stripping
> attachments, body prefixes, and so on) that would make l= useless.

I think the MLM document makes all of this stuff pretty clear already.

---

From: "John Levine" <[email-masked]>
Date: 31 Mar 2011 13:33:59 -0000

>prefixes, and after adding body footers. It's the list's signature,
>and the list's reputation that need to be assessed by the
>recipient. There are many other modifications that a list might make
>(like stripping attachments, body prefixes, and so on) that would
>make l= useless.

Quite right.  It would be helpful to me if people could explain what
problem they're trying to solve when they bring up mailing lists yet
again.  "Some lists break submitters' signatures" is a fact, not a
problem.  "I am trying to do X with my list mail, but I can't so I
have to do Y instead" would be a problem.

R's,
John

PS: "Someone might want to do Q, W, and J, even though nobody's ever
wanted to do it before" is definitely not a problem.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Al Iverson <[email-masked]>
Date: Thu, 31 Mar 2011 10:51:58 -0500

> I think the MLM document makes all of this stuff pretty clear already.

It does to me; it seems like dropping the original signature and
signing with the list manager site signature is the appropriate way to
go. I don't think I'd want to know that there is a use case where my
DKIM signature still passes after somebody modified headers. Good
intent aside, I see it being used for bad purposes too easily.

If you're worried about DKIM signing spam sent to the list address,
then that's a bit of a different problem, and it has a different,
non-DKIM-related solution.

Cheers,
Al Iverson

---

From: Hector Santos <[email-masked]>
Date: Thu, 31 Mar 2011 12:18:17 -0400

Franck Martin wrote:
> Silly question (?): 
> 
> Knowing that many mailing lists add [topic] at the beginning of the Subject line, 
> what if DKIM was set to ignore that part when signing/verifying?
> 
> I realize the issue would be to also detect the add footer, but if I recall 
> you can specify in dkim to sign only a certain length of the body and not 
> the whole body.

So are you proposing changes or a BCP for DKIM signing and verification?

    DKIM Signer Tips:

    - When signing messages targeted for a mailing list, you MAY
      consider using the l= tag to increase the survival
      rate of the message list distribution when a list
      footer as the only change to the body integrity.

      SECURITY NOTE: Please keep in mind there are replay
      exploits potentials with l= body length usage.

    DKIM Verifier Tips:

    - If a signature fails to validate, you MAY consider retesting
      to see if the failure was related to a subject line modified
      with [LIST-NAME] tag. Strip the tag and retest. You might
      also check if the z= tag is available with the original Subject:
      header value

But what about the other passive MLS-based mail tampering abeit 
industry-acceptable change options possible such stripping 
attachments, stripping HTML mime parts?

For our MLS software DKIM integration, I followed the expired DSAP 
proposed recommendations to first make sure there are no POLICY based 
restrictions and to exclude list membership for these domains.  An 
example can be seen at this subscription page showing the ADSP 
Restriction warning:

     http://www.winserver.com/public/code/html-subscribe?list=list-dkim

Try subscribing with any ADSP restricted domain email address, such as 
my test CatInTheBox.Net domain which has a DNS ADSP TXT record 
DKIM=DISCARDABLE and you will see a subscription deny response.

But once the member is allowed, we are doing the basic list submission 
mechanics of:

     - Verify original signature(s),
     - Add verification results with A-R header(s),
     - Modify/prepare message based on list option, which include
     - Strip original signature(s),
     - Resign with signer domain defined for the list,
     - Perform Distribution, there is no expectation of
       DKIM-related failure related to ADSP policies or
       related to broken original signatures.

One of the outcomes this was the suggestion of a new list option that 
basically offers an option such as:

      [_] Keep Original Mail Integrity

I like the idea because it is really a DKIM independent concept to 
offer list distribution features that are not alter list mail in any 
way.  But in a new DKIM aware mail environment, this "no mail 
tampering" list option can apply very well for a list with resigning 
or no resigning scenarios where retaining original mail signature(s) 
are desired.  The only change when resigning is the creation of a new 
signature which technically should not fail a DKIM verifier.

The main point I would like to stress is that we really need to begin 
to make DKIM something that is WORTH processing with well established 
conditions for GOOD and BAD mail filtering and reduced all the 
constant fuzzy mail designs that only continue to produce 
indeterminate results.   All that means is that if a domain is really 
seriously concern about its DKIM signed mail survivability and 
minimize all failures then the domain should avoid submitting these 
domain messages to "Meat Grinders" such as a MLS well known to operate 
with industry-accepted mail tampering features.

Higher survivability can only begin to occur as the MLS software are 
made DKIM aware.  I suggest there will continue exist older legacy 
software and most likely for many years.  But new or old, you will 
always need to be aware of the list operating behavior and what it 
does for DKIM directly or indirectly.

In all cases, you are just putting your domain, brand and reputation 
at risk if you sign your mail with an expectation they will have a 
high survivability rate.  IMV, the reason there is seems to be a 
continue aura of unsureness for DKIM is because we still have many 
failure conditions the DKIM Signer Domain Assessment model can not 
address.  It doesn't even address the NO SIGNATURE scenario.  So we 
left with limited DKIM utility where the only message to consider is 
one DKIM signed by a trusted source. Anything else has an 
indeterminate status.  All that means is I don't think it helps domain 
if it is going to go against this GOOD MAIL only idea by submitting 
signed mail to a list expecting it to survive when there is no current 
way to know what that list is going to do and the odds are very high 
it will break your original integrity.  At best, is for the author 
domain to be aware that list signer domain will take responsible for 
your copyrighted message by resigning it.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 31 Mar 2011 12:08:38 -0400

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Al Iverson
> Sent: Thursday, March 31, 2011 11:52 AM
> To: <[email-masked]>
> > That's also something we considered when talking to the Mailman
> people.  But again, this is really a small percentage of what causes
> author signatures on list mail to break.
> >
> and

+1

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 31 Mar 2011 09:33:34 -0700

On Mar 31, 2011, at 8:51 AM, Al Iverson wrote:

> go.

Yup.  The problem isn't that we haven't made this advice public (though it may carry more weight after last call.)  The problem is that it takes a long time for these ideas to disseminate to all list software deployed everywhere -- especially the outdated versions of MailMan that many sites run on autopilot.

FWIW, here's how I got DKIM signatures on messages resent by the lists I host with MailMan two years ago, without needing to wait for MailMan to update anything at all:

http://www.circleid.com/posts/dkim_for_discussion_lists/

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: "John R. Levine" <[email-masked]>
Date: 31 Mar 2011 13:44:34 -0400

> FWIW, here's how I got DKIM signatures on messages resent by the lists I host with MailMan two years ago, without needing to wait for MailMan to update anything at all:

Yup.  In most cases, it's really not hard to either tell the MTA to add a 
signature on the way out, or use a signing shim between the list manager 
and the MTA.  I did the latter with mj2, works great.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Thu, 31 Mar 2011 14:10:22 -0400

J.D. Falk wrote:
> Yup.  The problem isn't that we haven't made this advice public (though 
> it may carry more weight after last call.)  The problem is that it takes a 
> long time for these ideas to disseminate to all list software deployed 
> everywhere -- especially the outdated versions of MailMan that many sites 
> run on autopilot.
> 
> FWIW, here's how I got DKIM signatures on messages resent by the lists 
> I host with MailMan two years ago, without needing to wait for MailMan 
> to update anything at all:
> 

This is cool J.D.

The DKIM integration for our MLS was very simple and the outline I 
provided in DSAP (ideas covered in MLM as well) was written with the 
idea for a minimal software design,  no failure points promoted by the 
changes and simply plug and play with existing software.  It had only 
two MLS change considerations:

   - Restrict POLICY restricted domains as part of the list subscription
     process.  At the time DSAP was written, this meant disallow 
subscription
     for a domain using an exclusive signing practice which included a
     3rd party signing restriction.  If the policy allowed 3rd party 
signers
     to exist, then the user was allowed to join the list.

   - If mail changes will be done, strip old signatures and resign the
     message before redistribution.

We finally added this logic last year and the only MLS change was to 
add the subscription logic because we designed the framework for 
signing is done on the outbound MTA server.

The big change item I originally expected would need to be done in the 
MLS adding new DKIM signing options per list turned out to be 
unnecessary.  We avoided this big software by using the common list 
template file used to add additional headers such as all the LIST-* 
headers. I used a META header to trigger when a list should be signed. 
For example, the template file has:

List-Id: {LT} <{LN}.{LD}>
List-Post: <mailto:{LE}>
List-Unsubscribe: <mailto:{LN}-unsubscribe@{LD}>
List-Subscribe: <mailto:{LN}-subscribe@{LD}>
List-Help: <mailto:{CN}@{LD}?body=help>
WCLS-Signthis: {LD}

So the MLS will do its normal thing of preparing a list distribution, 
adding the list-* headers carrying the  meta header WLCS-SIGNTHIS: 
expanded with the list domain.  When the outbound MTA gets this 
internal feed, it looks for this meta header, extracts the 
list-domain, checks another setup file to signing options for the 
list-domain, if any. If found, any header striping options are 
followed and the list message message is signed.

So I guess the point is that you can make a MLS DKIM aware by using 
meta headers to current setup files and using that information as feed 
for edge software.

-
Sincerely

Hector Santos