On Wed, 2006-01-18 at 11:36 +0100, Aumont - Comite Reseaux des Universites wrote: > > From my understanding, the minimum is to preserve existing DKIM- > Signature: header and not modify the message in a way that will alter > the signature. For this issue, existing specification are quite clear > (the difficulties are only related to headers that must be preserved > where most available libraries to modify message headers don't garanty > headers length line and headers order).
Much of the requirements for a mailing-list will be determined by how DKIM becomes exploited and what resulting defenses are crafted. > It will be also very powerful to exploit DKIM signature as an method > when the context require to verify user privilege. This can replace > email confirmation challenge in many cases. This can be done also > quite easily. There is a risk related to relying upon just the DKIM signature. Any cryptographic signature can be replayed. Currently there is no provision within DKIM to adequately deal with this problem. One strategy could be to not sign messages sent to mailing-lists unless they are known to obfuscate the signatures and perhaps replace the signatures with their own. Should this strategy be used, then flattening of messages and adding the normal changes could continue. The From header may then need to have multiple addresses introduced, where the first email-address would be that of the mailing-list. It may also require that the From email-address be moved entirely into the body of the message and replaced with the email-address of the mailing-list. Even changing the From header will mean simple strategies to kill-file a participant will become more difficult. > What are the other issue related to mailing lists ? In which case the > mailing list server need to apply it's own signature to a message ? In my view, once DKIM is used as a basis for white-listing or basing acceptance of messages, mailing-lists will quickly become taboo unless the sender's signatures are obfuscated. <http://tools.ietf.org/wg/dkim> Some of these ideas are explored in this draft: <http://tools.ietf.org/wg/dkim/draft-otis-dkim-options-00.txt> Many of these issues will remain open until further thought is given regarding these threats. These concerns are currently being addressed by the document Jim is preparing. It appears the appraisal may be biased with a focus upon addressing the immediate problem of commerce emails being phished. Issues related to general use have been given less weight in the balance. Time will tell how well these concerns have been considered. -Doug _______________________________________________ ietf-dkim mailing list http://dkim.org
