ietf-dkim
[Top] [All Lists]

[ietf-dkim] How MUAs render mail (was: Data integrity claims)

2010-10-18 08:52:20
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.

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 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.

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.

c) Recommend that MUAs make it easy for users to recognize which
   parts of a message display are covered by whose (DKIM) signature.

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.

Of these, a) and d) solve the problem but are unlikely to happen,
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. Option b) is called layering violation and
c) is called kicking the can down the street.

        Wietse
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html