[ietf-dkim] Concerns about DKIM and mailiing lists

[Barry Leiba]

>> One note here: the base spec COULD suggest that if the signature fails 
>> to verify and the subject is signed and begins with "[", that the 
>> verifier might retry after removing the "[xxx]" part.  And then, much 
>> as with that part of the message that comes after the signed length, 
>> the verifier must decide what to do if the retry succeeds.
> 
> Not only would that be building a heuristic into the validation portion 
> of an otherwise precise security specification, it would be basing the 
> heuristic on an undocumented convention that is far from universal, 
> rather than on a a formal standard.
> 
> 
>> But in the worst case, the list has simply invalidated the signature, 
>> and we say that this SHOULD be considered equivalent to no signature 
>> at all.  Absent SSP, this is no bad thing.
> 
> I am inclined to agree.  However the [] behavior is rather common.  So 
> we probably should consider whether it is reasonable to have DKIM 
> contain features that are intended to allow a signature survive mailing 
> list transit, when we know that the final result will usually fail.

Dave, your two comments here seem contradictory: "We shouldn't try to 
handle '[]', because it'd be heuristic, but we should try to handle '[]' 
because it's rather common behaviour."  Do you have any ideas for 
handling it that don't throw us into heuristics?

I don't think there's a problem with verifiers applying some heuristics 
to this, given that (1) the signature is making a weak statement, and is 
not mean to be strong security and (2) this whole evaluation (the 
verification) is feeding into heuristics anyway ("What do I do with the 
message, given all the input I have about it?").

I appreciate Paul's comment, though, about spammers using that to their 
advantages.  Maybe it's part of the next-stage heuristics, where some 
hypothetical verifier considers "[ietf-dkim]" to be OK, "[Buy-Viagra]" 
to be <whatever>, and "[Come visit us at http://spam.example.com]" to be 
junk, using whatever next-stage heuristics it chooses.

I'm just afraid that the "[listname]" custom is sufficiently common that 
if we DON'T deal with it, we're throwing away too much opportunity to 
play nicely with existing well-behaved mailing lists.  So I'd LIKE to 
try to come up with a recommendation that helps (not a requirement, and 
not perfection).

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba at watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam