RFC4871bis primarily focuses on the mis-use discussions of "l=" but lacks functional descriptions for its proper usage. The only text that reflects a practical rationale is in section 3.4.5:
INFORMATIVE RATIONALE: This capability is provided because it is very common for mailing lists to add trailers to messages (e.g., instructions how to get off the list). Until those messages are also signed, the body length count is a useful tool for the verifier since it may as a matter of policy accept messages having valid signatures with extraneous data. The main issue, as we know, is that a mailing list will quite often do much more than just add a footer and section 3.4.5 lacks insights regarding additional considerations which may be required beyond using only the body length tag. I am proposing "starter" text changes in 3.4.5 and 8.1 in a fashion where all or part of the proposed changes can be considered. o Proposal: 3.4.5 should be retitled: 3.4.5 Considerations for using the Body Length Count o Proposal: replace the first paragraph with: There are certain use cases where an author domain may submit a message to an intermediary along the path that may add additional text which will destroy the originating authenticity of the DKIM message. DKIM provides an mechanism to address this scenario where a body length count MAY be specified to limit the signature calculation to an initial prefix of the body text, measured in octets. If the body length count is not specified, the entire message body is signed. o Proposal: For the INFORMATIVE RATIONALE, reword it as: INFORMATIVE RATIONALE: This capability is provided because it is very common for mailing lists to add trailing text to messages such as footers with instructions how to get off the list which in many nation jurisdictions has become a legal requirement for marketers to include in mail (i.e. CAN-SPAM). Until those messages are also signed, the body length count is a useful tool for the verifier since it may as a matter of policy accept messages having valid signatures with extraneous data. o Proposal: Not sure if this should be an informative implementator note, but after the INFORMATIVE RATIONALE add the following proposed "starter" text: Signers SHOULD NOT expect using the "l=" tag without other considerations to resolve losing the original integrity and authenticity of the message. There are intermediaries such as MLM (Mailing List Manager) which will alter the message in many other was than just appending a trailer text, such as altering the Subject line to prefix it with list name, changing/adding the Reply-To to help MUAs reduce its reply tendency to follow up/reply to multiple recipients, and for security purposes such as PCI, stripping attachments, HTML parts, etc may be performed. In general, the signer should be aware of the intermediary mailing list policy for mail content change, what headers are hash bound to the signature, and what contents parts are mostly to be stripped. o Proposal: Swap the text in 8.1 with the 3.4.5 INFORMATIVE IMPLEMENTATION NOTE For 3.4.5, change it to: INFORMATIVE IMPLEMENTATION NOTE: The use of the "l=" signature tag enables a variety of attacks in which added content can partially or completely change the recipient's view of the message. See section 8.1 for security considerations. and for 8.1 change the only paragraph with: 8.1. Misuse of Body Length Limits ("l=" Tag) Using body length limits enables an attack in which an attacker finds an existing DKIM signed message using the "l=" tag and and modifies to include content that solely benefits the attacker One example is changing unprotected mailing list footer to to maliciously redirect users using undesirable unsubscribing information. In addition, it is possible for the appended content to completely replace the original content in the end recipient's eyes, such as via alterations to the MIME structure or exploiting lax HTML parsing in the MUA, and to defeat duplicate message detection algorithms. To avoid this attack, signers should be wary of using this tag, and verifiers might wish to ignore the tag, perhaps based on other criteria. When the body length limit is used, it should highly noted that survivable rate is low when sending the signed mail to intermediaries such as a mail list which will alter other parts of the message, such as subject header and also strip mail content deemed security sensitive (i.e. attachments, HTML). See section 3.4.5 for proper usage considerations. To avoid potentials for this form of attack, signers should be wary of using this tag and have a complete awareness of the the intermediary (i.e. mailing list) message integrity handling practice including verifiers have the technical option to ignore the body length "l=" tag or perhaps handled based on advanced criteria or usage limits. --- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html