[Mailman-Developers] dkim-signature headers

[Michael Thomas]

Stephen J. Turnbull wrote:
> Michael Thomas writes:
>
>  > I'm afraid that there's not much consensus on how to deal with the
>  > mailing list issue; the people who say "resign" are guessing as there
>  > is little/no evidence that resigning is actually a viable strategy.
>
> From the point of view of the mailing lists, resigning is *clearly* a
> viable strategy; the draft mandates that signature processing SHOULD
> continue until a success or all signatures are exhausted.  (And it MAY
> continue after a success.)  Assuming conformant verifiers (and no
> corruption in the pipeline after the mailing list, of course),
> resigning by the mailing list guarantees successful verification.
>   

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; [...]

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.

>  > Do you remove PGP ascii armor just on the offhand chance that you might
>  > destroy a PGP signature with some  configurations of mailman?
>
> That's hardly fair.  Joe Petersen writes (in a response to your
> message):
>
>     2) The outgoing MTA (sendmail) milter seemed to only want to sign
>     emails that did *not* already have a signature.  Therefore,
>     Mailman enabled them to re-sign by removing the old (presumably
>     invalid anyway) signature.
>   

That is just an implementation detail of the sendmail milter. Mine doesn't
have that restriction and neither do others that I've seen. This is new code
in a new area so getting all worked up about how a particular implementation
behaves is not fair.
> First, note that the admin has explicitly stated that the existing
> signature is presumed invalid.  He may be wrong, but this isn't an
> "offhand chance".
>   

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? Well, the same is true of dkim signatures;
that you've come to the opposite conclusion seems to be based off of
experience with exactly one implementation that doesn't produce
mailing list friendly signatures. But that implementation isn't inherent
in the spec.

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.

> I'd like to see that last "should" in all uppercase<wink>.  
In RFC-speak, should and SHOULD are identical.

> Then
> (sorry, Barry!) IMO the burden is clearly on Mailman and other list
> manager projects to either implement signing themselves, or publish
> their own BCPs strongly recommending use in combination with an MTA
> that will do the signing.
>   
As I mentioned, part of the DKIM work is the SSP work as well. Being able
to say that "I sign everything" is a pretty powerful indication that you 
should
be more suspicious if you get a broken/unsigned piece of mail. So while I
think it would be great if mailman pushed signing too, I think that 
there are
other incentives for domains to bring mailing lists into the fold too.
>  > By removing signatures you go from having about a 99% success rate
>  > to a 0% success rate.
>
> That's false.  You go from a 99% success rate *on "loopback" messages*
> to 0%.  On other messages the ex ante success rate will be much lower
> because the trust relationship is on average much weaker.  However,
> the vast majority of *deliveries* are not "loopbacks", and those
> non-loopbacks are likely (see (1) below) to suffer from rejection on
> the basis that signatures fail.
>   

Huh? There's no difference between "loopback" and anything else: either
a signature verifies or it doesn't; we don't treat our own signatures 
any differently
than any other signatures. When using the l= option, almost all 
signatures will
verify. The only substantial difference between dkim and pgp signatures 
is when
a mailing list annotates the subject line of a new thread, but this too 
can be
worked around by intelligent use of z=. The only reason this isn't in 
the draft
is because we didn't want to get bogged down describing heuristics in a
standard (rightfully). All in all, I see no justification for doing 
anything different
for DKIM that you wouldn't also do the corresponding thing to PGP.
>  > With this change there will be a lot more people getting useless
>  > false positives. Is that of no consequence?
>
> Of course it is of consequence.  You keep ignoring the fact that
> Mailman has already experienced systematic useless false positives
> without this change.  Is that of no consequence?
>   

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.
>  > But let's turn this around: why do you think practice is helpful? I
>  > really don't understand the motivation at all.
>
> What I really fear is that
>
>     (1) everybody's intuition is that a failed verification is a
>         positive indicator for spam (as compared to no signature, as
>         well as compared to verified signature), and they want to
>         apply policy filters based on that---we can expect that lots
>         of people (and let's not forget AOL) will (ab)use the
>         information that way, and
>   

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.

>     (2) we've already seen list-hostile implementations in the wild---
>         we can expect that there will be more.
>
> Both of these are evidently conformant to the current spec.
>   

There are legitimate reasons to be "list hostile". Statements at bigbank.com
could probably care the least whether it survives a list, and in fact 
probably
thinks that it's a feature not a bug. Note that there is a significant 
faction of
DKIM proponents who are coming at it from that angle and from their
perspective it's a correct stance. We, on the other hand, want DKIM to work
in the more general user population case. So it shouldn't be surprising that
different sites/implementations will have different signing policies.

       Mike
>  > Destroying information -- especially when you're charged with
>  > forensic exercises like spam filters are -- is *rarely* the right
>  > thing to do.
>
> True, but this is a Pythonic bunch.  "Practicality beats purity." :-)
>