ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Lists "BCP" draft available

2010-05-11 11:04:17
On 05/10/2010 08:01 PM, Murray S. Kucherawy wrote:

I’ve posted an individual submission draft that attempts to capture some of the consensus and some appropriate guidance around the use of DKIM in the context of mailing lists.  I don’t propose that it’s final at all, but merely an anchor point for further discussion.

 

http://datatracker.ietf.org/doc/draft-kucherawy-dkim-lists/

 

That's a nice document. I would have be very glad to read it when I started DKIM implementation for Sympa. Sympa MLM  already respect almost all ideas described in this draft (see DKIM Sympa reference manual chapter : http://www.sympa.org/manual_6.1/dkim ).

  -Sympa include DKIM signature verification and use DKIM signature status in the process of message submission and email commands
  -it remove broken pre-existing DKIM signature and keep others as is (not all messages are processed in way that brake signature)
  -it reject message comming from  author ADSP record is discardable and if the process of message by the MLM brakes signature. This prevent brodcasting of a message that should be discarded by final recipients. 
  -it add it's own signature (on per list configuration parameter)
  -it sign MLM services messages and digest.
  - etc

I notice a good idea :  as Sympa verify incomming DKIM signature it should add a [AUTH-RESULTS] header field ; this header should be part of the DKIM signature added by the MLM engine. I will add this feature in Sympa in a near future.

Section 4.2

"Verifiers that receive mail bearing DKIM signatures that fail to verify might benefit from attempting to detect that such mail passed through a non-participating MLM and then decide not to apply [ADSP] in order to avoid aggressive filtering of mail that should otherwise have been delivered.".

This proposition may introduce a security issue : spammers could fake an sender email and a MLM engine in order to bypass ADSP from a particular domain. This proposition is a limit of what "ADSP discardable" mean. If we accept this idea that the final verifier may not test ADSP because the message comes from an non DKIM MLM, "ADSP discardable" is not usefull anymore. We all known that the use case of "ADSP discardable" is really limited.

Please remove this paragraph from this draft.

Section 3.4

At last, another idea usefulness is that draft in   :
"A possible mitigation to this incompatibility is use of the "l=" tag to bound the portion of the body covered by the body hash, but this has security considerations (see Section 3.5 of [DKIM])."

The "l=" tag is one of the worth idea of DKIM if introduced because of message body footer added by some MLM. MLM must not add anything after the end of a message because this break Mime content. When adding a footer, MLM should add an extra mime part, and this often require to modify mime headers. So "l=" tag should not ne considered as an efficient way to protect DKIM signature.

I known that the problem is comming from rfc-4871 but I  propose to remove this sentence from this draft.

Serge Aumont

 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html