[Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 7, 2007, at 11:45 AM, Michael Thomas wrote:

> I'm not saying I think that resigning is a Bad Thing, I'm saying  
> that it's
> speculative whether it's a Good Thing. You seem to keep ignoring the
> inherent attack involved with resigning:
>
> From: good at guy.org
> Sender: bad at fooledyou.com
> Dkim-Signature: d=fooledyou.com; [...]

So wait, taken to its logical conclusion, doesn't this mean that  
really the only thing that DKIM cares about protecting is the  
sanctity of the From header?  Tell me if I'm wrong but couldn't a  
spambot forge any header, create a valid signature for that header,  
and inject that message into the mail infrastructure?  It could even  
forge the From header and have a perfectly valid signature for that.

The reason From-forging may not be an effective strategy for the  
spambot though is because part of the point is to spoof the From  
header so that it looks like the spam is coming from someone you  
know.  OTOH, how many people would smell something fishy if this  
message had this header:

From: Barry Warsaw <barry at phyton.org>

?

> If all it takes to get preferential treatment (FSVO preferential)  
> is adding
> any old third party signature, then we can pretty much guarantee that
> spammers will start doing that when it's in their interest. The draft
> specifically refers to "acceptable" in this case for that reason.  
> This is
> the achillies heel of third party signatures: it presupposes that  
> you --
> or much worse your mail infrastructure -- knows what constitutes
> "acceptable". In practice I know that we as an organization have no
> clue who is acceptable, and I also know that even if we did, there's
> no infrastructure use/maintain it. I doubt that we're especially  
> unique
> here.

Then I think we're in a catch-22.  We'd like the MLM to sign the  
message to verify that it is a valid resender.  We'd like to keep the  
original signature for forensic reasons at the very least.  Resigning  
is vulnerable to attack.  There is no standard (de-facto or  
otherwise) for a valid resender to indicate "I got this message from  
so-and-so, munged it a bit, and resent it".  We're stuck.

You suggest that we just let the original signature through saying,  
well, that works most of the time and if it doesn't work for you,  
tough luck!  But whatever choices we make will be deployed in the  
field for years and years and if the 800lb gorillas start to take a  
much harder line two years from now, our mailing lists will be  
screwed.  I have a hard time seeing how, given the above scenario and  
inclination against resigning, that removing the DKIM signature and  
just letting our messages go through normal spam processing is worse  
than allowing a broken signature to sneak through.

> I think the question is quite apt: there are lots of transforms  
> that might
> damage PGP signatures as well: why aren't you stripping them en masse
> like you are dkim signatures? Could it be that it's because in  
> reality they
> normally go through just fine?

No.  It's because that would require a deletive transformation on the  
contents of the body (at least for OpenPGP) and Mailman doesn't do  
that[*].  Under a very controlled set of conditions, Mailman will / 
add/ text to the body of the message, and it may perform character  
set transformations, but in general Mailman isn't going to go  
searching through the body of a message to find some PGP delimiters  
to strip.

Signatures that are embodied in MIME parts can and may very well be  
easily stripped.

[*] the one minor exception is removing things like Accepted: headers  
from the body of the message, but this is tightly limited to the  
first 5 or so non-blank lines of the body.  Even then it doesn't work  
in the face of multipart/alternatives.

> Something to note is that a *lot* of the difference between DK and  
> DKIM
> was our insistence that DKIM be far more robust through manglers than
> DK was. This was purposefully so that survival through mailing  
> lists was
> much more likely -- something that a lot of people frankly didn't  
> care about.

Mailing list use cases are very often overlooked in email related  
RFCs.  Funny because so many standards discussions are conducted on  
mailing lists.

> Which false positives? I don't remember seeing that, and I've  
> certainly not
> seen anything in our deployment that suggests that bad signatures  
> are causing
> FP's on other domains incoming mail. After a year of deployment  
> signing
> millions of messages a day, I'd expect that I'd have heard at least  
> *one*
> report of that. Heck Y! and Google signing billions of messages a  
> day with
> DK which is a lot more fragile and I've never heard from either of  
> them that
> they are having FP problems due to broken signatures.

What kind of reporting infrastructure is there for false positives?   
ISTM they'd be very hard for end users to spot and report.

> Yet all evidence in my experience is that that is not correct.  
> Also: last I talked
> with the AOL guys they were planning to deploy DKIM as well, so they'd
> have a reasonable amount of incentive to understand the  
> implications on
> FP's and signature breakage. In any case, I think it's unreasonable  
> to be held
> to a standard that somebody, somewhere may have an overly aggressive
> filter; it's their problem honestly.

People complain all the time about never seeing messages posted to a  
mailing list.  The only thing we can do is tell them whether their  
message made it to the list, and to check their junk folders.  We can  
pass the buck to the users or their ISPs but the bottom line is that  
those kinds of aggressive tactics are employed all the time and there  
is often nothing the user can do about it.  See me previous rant on  
blanket IP blackholeing.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcoKEXEjvBPtnXfVAQL0SAQAgETzDXQqrjlmSmqwf2fspGgM0idZGi2R
piFWixLckRxEpqEqeKFWGS8DCqMprnZcfa4lQENRgOtBcQU0bH6QmpIgi0Y/XPI4
sRfhfHjNgd4HLdS0gKmDvJRwLdx/gcn8BGyLGAZbzAm0mabk3Z+TwexR7dYyhwOw
HNtZ2g6wZG0=
=H8ty
-----END PGP SIGNATURE-----