On 27/Apr/11 01:42, John R. Levine wrote:
I agree with Dave's changes,
+1, and also for Murray's advice of signing A-R fields. However, in
such case, the last phrase in Sec 7.2 (INFORMATIVE ADVICE to MUA
filter writers) should be changed from
To circumvent this attack, verifiers may wish to delete existing
results header fields after verification and before adding a new
header field.
to, e.g.,
To circumvent this attack, verifiers may wish to delete counterfeit
results header fields after verification and before adding a new
header field.
except that you need to sign Content-Type: if you use l=.
However, signing Content-Type affects a signature's robustness, due to
the possibility to add/remove quotes from MIME attributes during those
rewrites that l= is meant to pass through.
Otherwise it's trivial to replace the entire visible contents of
the message by changing the MIME section separator, and adding new
stuff at the end.
"Content-Type" is not currently mentioned in Section 9.1.1. "Addition
of new MIME parts to multipart/*". It should. Because it is now the
27th, I dare propose a replacement for that section:
If the body length limit does not cover a closing MIME multipart
section (including the trailing ""--CRLF"" portion), then it is
possible to add a new body part without breaking the signature.
This possibility can be abused. Depending on the details of the
MIME type and the implementation of the verifying MTA and the
receiving MUA, this could allow an attacker to change the
information displayed to an end user from an apparently trusted
source.
For example, if a message has a "multipart/alternative" body part,
an attacker might be able to add a new body part that is preferred
by the displaying MUA. Appending content to an existing body part
can also have surprising effects, as exemplified in the next
section 9.1.2.
Furthermore, if the top Content-Type does not appear (possibly
twice) in the h= tag, then it is possible to replace the entire
visible contents of the message by defining a suitable MIME
multipart/* and its boundary, so that the signed content appears to
only cover a MIME preamble and/or invisible MIME entities.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html