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