#acl stephen@xemacs.org:read,write,delete,revert All:read
#pragma comment-owner stephen@xemacs.org
#pragma page-filename DEV/versions/835
=== Re: Problems with Mailman signing headers ===

You write that a Mailman signature could potentially "legitimize otherwise illegitimate message".  Technically, this is confusing language.  "Legitimate" is a local policy decision and will surely vary from site to site.  I would express this kind of idea as "result in recipients accepting spam and undesired messages that they otherwise would reject."

You suggest not signing gated messages.  This has its own problems, specifically that (1) it is useful to promise to sign all messages, but the list is deliberately not signing some of its output (2) many sites that know that this list signs will drop all unsigned posts.  A plausible alternative strategy would be to sign Usenet-gated posts with a different key.  I don't think this is generally going to be more than minor extra effort, as any decent  signing agent will be prepared to deal with selectors.  (I suppose this is mandated by DKIM, but I haven't checked.)

=== Re: Proposal ===

The language for 2.1.10 is excellent.

For 2.2/3.0, shouldn't all RFC 2369 headers be signed to prevent phishing attacks?  Sender should be signed for Mailman's own potential benefit, I think, and of course DKIM itself mandates signing From.

The discussion of the DKIM status header should remark that DKIM does not even suggest a format for these headers, so they will be implementation-dependent.  I think a call for Mailman advocates to participate in specification of a standard header, as well as to help with implementations' headers in the meantime, may be warranted.

Regarding the call for verifiers to "look favorably on" verified list signatures, I'm of two minds.  Technically, I think it's a bug in the DKIM spec that it doesn't thoroughly distinguish between verifiers and policy agents (not to mention that it fails to mention the role of policy agents for the signing decision at all!)  So I don't like language that suggests that verifiers make policy decisions.  There's plenty of precedent for it in the latest DKIM draft, though. 

Language to the effect that verifiers MAY make extra effort to find a valid list signature in the case where broken signatures are found is definitely appropriate, though.

As Michael has repeatedly emphasized, very little is known about the pragmatics of re-signing.  Nonetheless, I think that a better way to try to accomplish this is to have a Mailman implementation that wants to take responsibility for broken signatures is to sign those signatures.  (Remember, it can also create another signature without signing them.  Then the signature signature might fail due to an intermediary reordering DKIM signatures, but the signature of the post itself would succeed.)

Then the BCP for policy agents could say that the presence of a broken signature which is nonetheless verified by a valid signature SHOULD be considered an indication that the verified signer verified the broken signatures on the way in, and that the verified signer then broke them.  (This doesn't mean that a policy agent should trust the  broken signature.  That depends on how much it trusts the verified signer.)

Without signing the signatures, there's an obvious vector for reply attacks.  I don't think that can be written into the standard or BCP.