ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-17 12:34:15
On August 17, 2005 at 15:15, Keith Moore wrote:

So for instance a verifying MUA that displays an indication that a
message was signed should display the original message, rather than the
modified message.  If it provides an option to display the modified
message, it should make it clear that the message was modified in
transit after being signed.  (I can imagine an MUA showing diffs
between versions with strikethroughs, underlines, and change bars, but
I doubt most recipients would bother with such.)

Seen from that perspective, a filtering verifier might reasonably pass a
signed message if the original content could still be recovered and
verified by the filter, and presumably, by any subsequent verifier and
the recipient's MUA.

Agreed.

I was just stating the initial state of the DKIM draft.

What you have described has been touched upon before, but it
appears to have gotten little traction.

To do what you describe will require more involvement by the verifier,
with some issues depending on who does the verification.

If the MUA does it, showing the original and modified forms
is straight-forward (assuming the original is reconstructable).

If done at the MTA-level, a decision needs to be made if the MTA
will reconstruct the original and "discard" the modified version.
This leads into discussions about the value of the modified version
and if it is acceptable to discard it.

With header fields, the modified forms can be "saved" into separate
fields so the data is not lost.  As for the body, such data saving
is not viable.

--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org