[Mailman-Developers] dkim-signature headers

[Michael Thomas]

Barry Warsaw wrote:
> -----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?  
No, it doesn't. All it means is that you shouldn't blindly allow a third 
party
to vouch for a first party (or any other party for that matter). This is 
just
common sense: you need to have some trust in a third party before you
trust what they have to say about another party, right?
> 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.

It can do all of those things _except_ create a valid signature for
a domain that it does not control their DNS (ie, the repository for
the public keys).  That is, you can't forge cisco.com or python.org
if you can't put your keys in our zones. This is really a feature if you
consider it: making an environment where spammers have to sign
their mail limits their degrees of freedom: they have to leave more
tracks by registering domains, etc, etc.
>
> 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>
>
> ?

Er, I'm not following you. A lot of the motivation around DKIM was to
limit the wholesale forgery that's possible now. If I could guess what you
mean here is that you mean that it lacks a signature at all? That's 
where the
SSP part of the work comes in: if you receive a piece of mail that's 
unsigned,
you do a lookup to see what the originating domain's policy is with respect
to signing mail. If they say "we sign everything", a receiver has a 
pretty good
indication that something's not right and may bias the filtering and/or 
annotation
accordingly.

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

Yes it is. At this point I'm not pessimistic though; from my point of view
it's more that we're just not sure how it will pan out. From that 
standpoint,
we need to keep _all_ of the options open which means that it's prudent
to _both_ try to get mailing lists to be dkim friendly for first party 
signatures
_and_ resign things so that reputation engines, etc, have something to
latch on to.
>
> 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.

Frankly I think you'll be screwed even if you remove them too; removing
them will not allow you to fly below the radar. Consider if Y! and Gmail
had a bilateral agreement that they expect each other's mail to be signed
and to put it in the bit bucket if it wasn't. It makes no difference whether
you removed it or not: it lacks a valid signature in both cases. In that 
case,
the only thing you could do is not destroy and/or remove the signature.
>
>> 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.
Or base64 to QP or... My point is that you're holding DKIM to a standard
that you don't hold PGP to.

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

Right, but at least in my experience they seem to get through... but this
is why a "signature friendly" theme may well be useful. Probably a lot
of list owners aren't even cognizant that there is a tradeoff that is made
when they do their demimulating, etc.

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

Tell me about it :|
>
>> 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.

Right -- they are, but it's not impossible, and with list traffic I 
think it's
actually easier to spot. Given how much a lot of the upper level geeks here
live and die by external mailing list traffic, I'm pretty sure that I'd 
have
heard about it by now if it were a real problem (and heard, and heard,
and heard...).
>
>> 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.
Correct (and I'm in the same boat with your IP blackhole rant), but until
there's a real life problem it's really sort of pointless to try to 
guess, IMO.
As it turns out, the law of unintended consequences reared its head yet
again, and voila here I am! :)

       Mike