On Sat, 2006-08-26 at 21:52 -0400, Hector Santos wrote: > What Frank is saying is the ISP.COM has all power to control this and > protect his users from direct DKIM phish attacks in a very elegant and > graceful manner using SSP. > > The phisher has harvested hundreds or even thousands of users at > ISP.COM and he knows ISP.COM always signs mail. > > The phisher sends mail to the ISP local users. No SMTP authorization > is required because it is local mail (not routed). That's BCP.
Not when 2822.From i=syntax of the 2822.From being valid one would hope. This would be a bad practice from the standpoint of security. > In the bare bone DKIM-BASE ISP implementation: > > The ISP signs the message and delivers it to local users. DKIM > PHISHING LOOPHOLE! Unfortunately that "loophole" exists in many forms. - A signature added by the sender that should not be removed according to the base draft. - A message signed by ISP.com that still has the audacity to allow users a choice of 2822.From email-addresses. - A message sent directly from a compromised system somewhere. DKIM offer no protection without annotations. DKIM Designation should be annotated differently than messages where the 2822.From address and the signing domain match. Add to that strategy an annotation when the valid 2822.From addresses also seen in the address book. These two steps can comprehensively defeat most phishing attacks that use look-alike domains. The problem of look-alikes will only grow worse and is not prevented by taking away everyone's freedom. > In the "Smarter" SSP Ready ISP implementation: > > The ISP.COM should have his own list of domains the ISP will sign for > to check against. The ISP will check the From address SSP policy and > it will see that it is designated as an authorized signer. However, > if EBOY.COM is not in the ISP list of domains he is signing for, then > it should not accept this message or see it as suspicious. DKIM > Phishing Problem Solved!! The ISP's users are protected and EBAY is > indirectly protected too. An option should be added to DKIM aimed directly at conveying whether the ISP has validated the 2822.From address. One might assume this process also applies a block-list of known problem addresses as a best practice. Unfortunately this validation can not be conveyed when the 2822.From domain is not within that of the signing domain. This is a security flaw. An assurance of having validated an address out of the signing domain improves security. It would also be useful at better encouraging this desired mode of operation. Good idea, but it needs a way to indicate when this verification has happened. > To maximize protection all 3rd party signers should check the > originating domain SSP policy to see if it is allowed to sign. Sorry, many ISPs may decide to ignore DKIM altogether. There are still other modes where a look-alike attack with DKIM remains viable. The solution is to ensure the 2822.From _always_ offers an assurance of being valid, and that this address is also found in the address book. This could be strengthened by also indicating when the signing domain has validated the 2822.From without reliance upon the self limited i=syntax. Perhaps the i= syntax should be revisited or something. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
