At 20040810 0623 "Jim Fenton" suggested:
At 05:56 PM 8/9/2004 +0100, Chris Haynes wrote:
"Rand Wacker" replied:
On Sat, 7 Aug 2004, Chris Haynes wrote:
The draft states that "in order to avoid this attack, MUAs will need to
start
displaying at least the header that was verified".
My concern is the need for new MUA purchases.
Why can't the server-side check modify the message to display the results
in an MUA-compatible way similar to the way that SpamAssassin modifies
bodies and (optionally) headers today?
-Rand
Could you please supply an example of the modifications you propose in such a
way that:
1) It is displayable in Outlook Express
2) The display could not have been forged by the sender
I share Chris's concern. Unless the PRA is displayed prominently to the user,
the > From address (when it isn't the PRA) can be anything it wants.
I'm not an OE user, but I'd suggest something like the following:
The MTA verifying the source of the email would rewrite the From line to
something like:
From: {original From address} via {PRA address}
Do you mean like the To: part of this eMail?
AFAIK the only way to get OE to display anything like this is to put the text
into the displayable version of the address.
This contaminates the address used in the Address Book, used in replies,
forwards etc.
Now how about preventing forgery?
I think you suggest that receiving MTAs should strip off any pre-existing 'via'
text before adding its own.
Look closely at my demonstration. Would your MTA strip this suffix?
Would the user read it as "via PHISHER" (hope you've got crisp glyphs in your
display)?
In which RFC do we make "via" a prohibited word in the free-text part of
addresses?
Exactly which character sequences do we prohibit?
How about encoding "via" in octet encodings intended for the display of
non-US-ASCII?
And what about the cases (listed in my Saturday eMail
Security issue: End-user dependence on MTA integrity" 40040807 11:59) in which
the last MTA in the chain is not undertaking the tests? Forged "via"s could get
straight through without being challenged.
It would also copy the original From address into a newly-created header,
perhaps >Originally-From:
Useful in OE only to those who know and understand the "RightClick-Properties -
Details" dialog sequence.
There needs to be a chain of trust between where the source of the email is
verified
and the recipient. I believe that is needed whether you do the rewriting I'm
describing or not. If that chain of trust exists, the sender shouldn't be
able to forge it.
I absolutely agree that any time we display information to the user a chain of
trust is needed.
My points are:
1) The drafts on the table today do not provide even the basis for such a chain,
2) I would be very surprised if there are many MUAs in the consumer market today
which have the capability to play their role in that chain - by displaying the
information to be trusted in a way which (a) cannot be forged and (b) does not
contaminate the message itself.
That's why I have suggested to the authors of -core-02 that their "Security
Considerations" section needs to be much more candid about this difficulty in
displaying the PRA in a trustworthy way, and that both the draft and the IETF's
decision-making process needs to understand (what I believe is) the need to
replace a large proportion of the world's MUAs in order to provide the
trust-worthy display of the PRA, which is an _essential_ aspect of Sender-ID.
-Jim
HTH
Chris