Dave CROCKER wrote:
Two quick reactions about the first part of the ticket:
1. This is just a variant of the basic hole created by use of l=
2. The premise that having the l= go to a multipart boundary
somehow increases security is simply wrong. More generally,
the idea that one or another tidbit might tighten things
a bit, l= opens such a huge door, the small tidbits don't matter.
As for the second part, with or without Content-Type, messing with
the message in any interesting way will break the signature.
+1.
Reviewing all peppered information in the document regarding l=, you
will find a reference in all these sections.
4.5. The DKIM-Signature Header Field
4.7. Computing the Message Hashes
5.1. Example Scenarios
6.5. Recommended Signature Content
6.6. Compute the Message Hash and Signature
7.1.3. Compute the Verification
9.1. Misuse of Body Length Limits ("l=" Tag)
Appendix D. MUA Considerations
I find the repeated concerns regarding l= and I also see it may imply
l= is assumed to be used when in fact it may not. Overall, we should
consulate all the l= concerns to one place (references to section
where applicable).
In section 4.5, 1st sentence for bh= description, it can lead to
confusion a "l=" will be included in the DKIM-Signature. We certainly
do not wish to mistakenly cause implementators to set l= when not
necessary. I rewording might be:
bh= The hash (base64; REQUIRED) of the canonicalized body part
of the message. It is limited to the entire body length
count or length explicitly set with optional "l=" tag count
value. If the hash is to represent the entire body with
no expectation for additional unhashed text appended to the
body, the l= tag SHOULD NOT be used. (See Section 9.1).
For the l= description, I proposed removing the INFORMATION
IMPLEMENTATION WARNING and change the paragraph;
l= Body length count (plain-text unsigned decimal integer; OPTIONAL).
By default, when l= is not used, the count is entire body. The
length represent the canonicalized message body used for the
body hash as defined for bh=. If defined, this tag informs the
verifier of the number of octets in used for the body hash,
starting from 0 immediately following the CRLF preceding the
body.
This value MUST NOT be larger than the actual number of octets
in the canonicalized message body. See Section 9.1 for security
related issues concerning the use of l=.
In section 4.7, 4th paragraph, 1st sentence, it can also lead to idea
the l= tag is going to be used and needs to be part of the
DKIM-signature. A rewording might be:
In hash step 1, the signer/verifier MUST hash the message body,
canonicalized using the body canonicalization algorithm specified in
the "c=" tag to create the "bh=" tag (See section 4.5). Setting the
"l=" body count should only be set if the entire body is not going
to hash. See Section 9.1 for security related issues concerning
the use of l=.
In section 6.5, last paragraph, I think it should be moved to either
4.5 or 9.1. This section is about headers to consider and that last
paragraph has no connections to header, unlike the 4th paragraph which
describes a l= condition to consider Context-Type header.
In section 6.6, last paragraph, last sentence, it once again can lead
to the suggestion that a "l=" should be used when it may not be
necessary, but in this paragraph I believe there is MUST requirement.
Rewording might be:
The signer MAY elect to limit the number of bytes of the body that
will be included in the hash and hence signed. When the number of
bytes is less then the actual body length, the number MUST be set
in the "l=" tag and added to the DKIM-Signature header field.
In section 7.1.3, itemized step 1, once again, there is a suggestion
the "l=" will be expected to be present. Possible rewording
1. Based on the algorithm defined in the "c=" tag, the entire
body length or length limited by a "l=" tag value, ......
Similarly in section 7.1.3, last paragraph, it infers an existence of
the "l=" tag. A possible rewording:
When the "l=" tag is found in a DKIM-Signature, the value limits the
number of bytes of the body passed to the verification algorithm.
I guess overall, with the above changes the intent it to not encourage
the natural use of the harmful "l=" tag when not necessary.
I think the final l= reference in Appendix D for MUA Considerations is
a good practical consideration for MUA developers.
Finally, since the l= is controversial, limited in areas of usage, all
the notes regarding the misusing "l=" and security related concerns
peppered in the document should be consolidated under 9.1.
--
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