On Mon, 2004-12-06 at 13:26, Jim Fenton wrote:
Dave Crocker wrote:We should make the goal of mass to be validation by a receive-side filter. Any dependency or expectation of displays to the user -- never mind concern for having the user somehow decide whether the message is valid or not -- should be entirely beyond the scope of this effort.
Yes the base standards should not address validity or semantics of what being singed might imply. You need more mechanism to even begin to address those concerns. They are also much more immature.
Here's the attack I'm concerned about: Suppose someone generated a phishing attack supposedly from Example Bank, security(_at_)example(_dot_)com(_dot_)
Ok so the phishers use security(_at_)example-bank(_dot_)com instead. A lot of people would be caught off guard by that.
If the recipient gets the message and just sees that it is signed, the message signature may actually be helping the attacker by making the message look more real. If the answer to this is the use of accreditation/reputation systems,
Well at least they should have their own banks white-listed, especially because fraudsters have been known to use look-a-like domain names to fool people. And some organizations use could use either short abbreviation and/or long form .. If you really want to use a message for something then you need to know who you trust and for what purposes.
well OK, but that's a much stronger dependency on such systems than I thought we had. If, on the other hand, someone gets this message and sees that it was (allegedly) sent by their bank but signed by some unknown third party, it raises legitimate suspicions.
Unless that third parties domain name is designed to be confusingly similar. That has been known to work on people. But yes signatures by themselves mean very little, its just means a bag of bits passed through a system. The end-user needs to be vigilant that the email that seems to be from his bank is really signed by example.com and not attackerdomain.com nor example-bank.com . In the real world the phishers are likely to look like sheep and use confusing domain names, not beware-warning-phisher-attack-scam.com . So having some automation machinery to help the e-mail readers could be real helpful.
By the way, do we have consensus on what the semantics of the signature are?
A Bag O' Bits passed through a system. Those bags O'bits might have been generated by third-parties like foo_guy(_at_)hotmail, or I_am_a_great_guy(_at_)yahoo(_dot_)com, or lkml-reader(_at_)example(_dot_)com so you shouldn't trust them to represent the official policies of the domain holders. You also should not take them to be authorized agents of the domain holders. For banks that means they should give *prominent* *notice* that their signing message doesn't confer any apparent or ostensible agent status to any individuals sending email through their system. AKA without mechanism to express the additional semantics, then digital signatures by the banks is likely DOA. If you want to add more semantics to what a signature means you should also use rdf and/or accreditation/reputation system(s). Otherwise you don't know whether it's is from a random yokel that signs up at yahoo, or a well-crafted fraud message, or some pissed-off bank janitor. -- http://dmoz.org/profiles/pollei.html http://sourceforge.net/users/stephen_pollei/ http://www.orkut.com/Profile.aspx?uid=2455954990164098214 http://stephen_pollei.home.comcast.net/ GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677
signature.asc
Description: This is a digitally signed message part