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