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
