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