Subject: [ietf-dkim] issue: section 3.4.5 & 8.1 Clarifying "l="

From: Hector Santos <[email-masked]>
Date: Tue, 10 May 2011 00:22:33 -0400

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