Good analysis. A few comments embedded below. Aumont - Comite Reseaux des Universites wrote: > > Lets try to identify the different possible cases when a signed > message is received by the mailing list server. There are 3 actions > that the mailing list server can do : > > - 1/./. : Add a mailing list server signature or not > - ./1/. : Remove existing signature or not > - ././1 : Modify the message in a way that breaks DKIM signatures or not > > So we must examine benefits and problems for 8 cases : > > ------------------- 0/0/0 : > -The list server does not add a signature/ > -does not remove the existing signature / > -does not modify the message / > The message is distributed with a valid signature. The original > sender reputation will be used by final RCPT to evaluate the message : > the mailing list server is transparent forwarder but final receipient > can't use DKIM signature in order to prove that the message was > relayed by the list. > > ------------------- 0/0/1 > -The list server do not add a signature/ > -do not removes the existing signature,/ > -modify the message,/ > > BAD : the message is distributed with invalid signature, this valid > message will probably be suspicious for many rcpt > > ------------------- 0/1/0 and 0/1/1 > -The list server does not add a signature/ > -removes the existing signature, / > -does not modify the message or not > > The message is distributed unsigned. > If the sender SSP specifies that all messages from this sender must > be signed then this message is suspicious. Case 0/0/1 should be included here as well, because invalid signatures need to be considered exactly the same as missing signatures, neither better nor worse. See http://www.mhonarc.org/archive/html/ietf-dkim/2006-01/msg00085.html for the rationale for this. > > > ------------------- 1/0/0 > -The list server adds a signature. > -does not remove the existing signature,/ > -does not modify the message > > A) the mailing list server adds a signature i= (signer) and "From:" > are different. The signature may be invalid if the sender SSP does not > allow third party signature. > > B) Possible scenario for replay attack > A BAD actor could exploit a un-moderated opt-in mailing list in order > to subscribe, send a spam to the list, receive its own spam signed by > the listserver in order to replay it. This would affect the list > server reputation but also the original sender reputation unless he's > signature is removed or altered by the distribution processus. We shouldn't make any assumptions about the way the reputation system operates; remember that it could be a local, manually-maintained white list as well. Accreditation could be used here as well, especially by larger list providers. > > A and B are true for any of 1/x/x (if the original message is modified > or not and if the original signature is removed or not). > > How can this signature be used by the final rcpt ? > What is it usefull for ? It can be used to prove that the message was > relayed via the mailing list but usualy, when this is needed the list > archives can prove it. Checking the archives works fine after the fact, but doesn't help in the handling of the message. If I want to treat certain messages preferentially, perhaps because they come from the ietf-dkim mailing list, I'd like to make that decision based on a signature. Active participants in a list are likely to treat the list preferentially, and it's very easy to see who they are. So an attacker might try to spoof the list to get someone to read a message. > > The list reputation can be used but to my mind, the original sender > reputation seems to be the reputation that should be used. > > > Other cases are variant of 1/x/x and 0/x/x that cumul problems from > both categories. > > > At the end, I can't identify the reason why a mailing should add a > signature to a message, may be because I didn't understand how third > party signature can be used with a signer (i=) different from the > message Sender. Also I can't see how MUA could deal with message with > multiple From: . It is definitively not a common usage and it will not > be accepted by users because it suppose some modification in MUA. We should stay away from multiple From: addresses; MUA behavior is inconsistent (we have done a few experiments).
-Jim _______________________________________________ ietf-dkim mailing list http://dkim.org
