On 10/18/10 6:49 AM, Wietse Venema wrote: > Mark Delany: >> My problem is that if some valuable domain like paypal sends me a >> bunch of bits that I or my MUA or my MTA ties to paypal.com then the >> end goal of DKIM is, IMO, that those bunch of bits I "see" are the >> ones that paypal sent. No more, no less. Be careful not to limit concerns to what is displayed, since DKIM results also affect how mail might be sorted or filtered. > But the user does not see a bunch of bits. The user sees the combined > result of software layers that render those bits. DKIM has no > control over that rendering process. DKIM never controls the rendering process. DKIM only controls the verification results being reported. > DKIM can only guarantee that "what you RECEIVED is what I signed". > To get "what you SEE is what I signed" semantics, one could do the > following: > > a) Exchange all email as static image files. Static image files would not correct the mistaken application of DKIM results on illegally pre-pended From header fields used for sorting, for example. The only sure method to deal with these types of exploits would be to prohibit such messages from receiving a DKIM PASS. > b) Make DKIM verifiers aware of all possible ways to exploit the > message rendering process without breaking the DKIM signature. > For example, prepend extra Subject: etc. header; add message > header with JAVASCRIPT that overlays part of the message display; > add other out-of-spec content, or corner-case within-spec content. Close. By now few MUAs permit scripts to automatically run. Some make handling exceptions when the From email address is found in their contact list, which can also be conditioned upon obtaining a DKIM PASS. > c) Recommend that MUAs make it easy for users to recognize which > parts of a message display are covered by whose (DKIM) signature. The DKIM l= parameter makes displaying results of multiple signatures problematic. Clearly, DKIM did not consider how partial signature coverage might be conveyed. Only the From header field stands out as an exception for DKIM and ADSP. > d) Go back to non-MIME ASCII-only email, use fixed-width fonts > on 80-character displays and only mandatory, single-instance, > non-folding headers. DKIM does not need to limit email in this manner to provide reasonable protections, which is still not afforded by ASCII-only email without also RFC5322 compliance. > Of these, a) and d) solve the problem but are unlikely to happen, Disagree. Neither a) or d) solves the problem.
> while b) and c) address the same problems in different places and > will need to be revisited every time some new exploitable MUA > feature is introduced. Agreed with respect to b), however as a general rule, scripts obtained from unknown sources should not be executed. > Option b) is called layering violation and Agreed, b) would be a layering violation when it involves anything other than the formulation of a DKIM result. However, unlike an MTA, DKIM is rightfully concerned with the proper structure of the RFC5322 message to prevent exploits. > c) is called kicking the can down the street. Fully agree. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html