RE: ACTION-4 contact/capture use case

I think we need to break these out as a hierarchy.
 
There are indeed passive phishing attacks obscurantists refer to them as 'lobster pot phishing'. From the context point of view there are important differences since these sites tend to be up for much longer lengths of time but with significantly lower returns.
 
Another variety of this scheme is when a Domain name gets snapped up by a squatter after a company has failed. There was a company selling parts for MGBs where this essentially happened.
 
 
Phishing gangs prefer email and push technology because they do not require the target to initiate contact. They can reach millions without any prior contact. 
 
So we should probably state the abstract phishing case and then break out email/Web as being a prefered attack modality. We should probably also note that there is an email/VOIP attack modality that is increasing in frequency that is (currently) out of scope.
 
 
I think that when we are declaring scope here we should work from the assumption that we succeed with phase one of the project and provide useful context ideas for HTTP/HTML and that based on that success it is likely that a followon project will look at extending the same set of concepts to other modalities such as SMTP, VOIP etc. This has the added benefit that by that time DKIM will hopefully have their base specification accepted as a standard and we can propose ways to work off that foundation.
 
Clearly Email is going to need to be cleaned up. Even if the statement that comes out of W3C is as simple as 'don't execute arbitrary javascript in HTML emails from unknown sources' thats useful. But we have to do HTTP/HTML before we can cast the net wider.
 
 
The importance of these use cases is that they are the interface from one form of communication to another.
 
When we surf from one Web site to another we do not lose the context information due to the application program handover in the same way that we do jumping from Email to Web.
 
 
But this does highlight an important opportunity here. Perhaps a piece of metadata that allows a WebMail site or a blog with comments to tell the browser 'these links should not be considered as being within my trust domain caveat emptor'. So in the case that a browser has good anti-phishing built in it can know that it should be using them in this case.
 
This information would also be useful to search engines.
 
 


________________________________

	From: Mary Ellen Zurko [mailto:Mary_Ellen_Zurko@notesdev.ibm.com] 
	Sent: Wednesday, November 22, 2006 12:10 PM
	To: Hallam-Baker, Phillip
	Cc: public-wsc-wg@w3.org
	Subject: ACTION-4 contact/capture use case
	
	

	Phil, good statements around contact and capture as well. I agree with your abstraction on contact, though I would add a non-push technology to the examples, such as some sort of shared community/bboard area (social networking, craig's list type things) and/or a web page meant to capture certain kinds of searches to then tempt the user to the false BobBank. 
	
	          Mez
	
	Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
	Lotus/WPLC Security Strategy and Patent Innovation Architect
	
	
	
	
"Hallam-Baker, Phillip" <pbaker@verisign.com> 
Sent by: public-wsc-wg-request@w3.org 

11/20/2006 08:17 PM 

To
"Stephen Farrell" <stephen.farrell@cs.tcd.ie> 
cc
<public-wsc-wg@w3.org> 
Subject
RE: Action Items - check your due dates

	




	
	These comments can be added directly to the discussion section as is.
	
	Only point to clarify maybe is that in the case of WebMail there are two security contexts that have to be authenticated to the user, the context of the message and the context of the WebMail provider.
	
	
	> -----Original Message-----
	> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
	> Sent: Monday, November 20, 2006 6:44 PM
	> To: Hallam-Baker, Phillip
	> Cc: public-wsc-wg@w3.org
	> Subject: Re: Action Items - check your due dates
	> 
	> 
	> Two additions to this:
	> 
	> 1. Since the user may be using webmail there's no absolute 
	> need for a separate MUA in this scenario.
	> 
	> 2. The incoming mail may have some markings (e.g. DKIM 
	> signatures, or authentication results) that could be 
	> beneficial (e.g. if the UA itself maintains state).
	> 
	> S.
	> 
	> Hallam-Baker, Phillip wrote:
	> > 
	> >   ACTION-4
	> > 
	> > 
	> >     Formalize the scenario of user getting a request via e-mail and
	> >     using that information to contact a web-site using HTTP protocol
	> >     (e.g. using a browser)
	> > 
	> > 
	> >   Alice is a customer of BobBank. Mallet is an attacker 
	> attempting to
	> >   obtain Alice's access credential for the BobBank site by 
	> impersonating
	> >   BobBank, first in email and then as a Web site.
	> > 
	> > 
	> >   Mallet sends Alice (and a million other users) an email 
	> that purports
	> >   to come from BobBank. The email may claim a sender address that is
	> >   used by BobBank (accounts@bobbank.com 
	> <mailto:accounts@bobbank.com>),
	> >   an address similar to that used by BobBank (accounts@b0bbank.com
	> >   <mailto:accounts@b0bbank.com>) or an entirely unrelated 
	> email address
	> >   (accounts@as818d2182.ru). <mailto:accounts@as818d2182.ru).>
	> > 
	> > 
	> >   The email purporting to come from BobBank directs Alice 
	> to a web site
	> >   that looks very similar to the authentic BobBank site. 
	> The email link
	> >   may use a cousin address (http://www.b0bbank.com), a 
	> numeric address
	> >   (http://10.1.1.1), a numeric address with a fake username portion
	> >   (http://www.bobbank.com@10.1.1.1/). In many cases the 
	> user is shown a
	> >   URL that is different to the one that is actually linked.
	> > 
	> > 
	> >   In some cases the Web site will be implemented as a proxy to the
	> >   genuine BobBank site, in others static HTML and image 
	> file data that
	> >   has been 'screen scraped' from the authentic BobBank site. The
	> >   objective of this site is to persuade Alice to enter her 
	> username and
	> >   password so that Mallet can record it and either use it 
	> to access the
	> >   site at a later date or to sell the information for a 
	> third party to
	> >   make use of in this way.
	> > 
	> > 
	> >   At the time Alice attempts to contact the impersonating Web site
	> >   BobBank may have been alerted to the existence of the 
	> impersonating
	> >   Web Site by a number of channels: A customer, spam 
	> control company or
	> >   anti-phishing company may have explicitly made contact 
	> and alerted the
	> >   bank, the use of the genuine sender address may have caused a
	> >   'backwash' of failed email delivery attempts, previous attempts to
	> >   connect to the site as a proxy may have been detected.
	> > 
	> > 
	> >   Alice and BobBank both have assets at risk. Alice may 
	> lose funds from
	> >   her account that are not reimbursed. BobBank may be required to
	> >   reimburse Alice for funds taken from the account. In addition to
	> >   direct losses due to fraud BobBank may suffer indirect 
	> losses due to
	> >   increased customer service calls whether or not the attack is
	> >   successful: Alice may insist on doing all her future 
	> transactions at a
	> >   local branch at significantly higher cost to the bank. Alice may
	> >   contact customer service to ask about the attack.
	> > 
	> > 
	> >   Discussion
	> > 
	> > 
	> >   In each case the attack has two disftinct phases: contact 
	> and capture.
	> >   In the contact phase Mallet solicits interaction with a 
	> large number
	> >   of potential victims using a medium that supports unsolicited
	> >   interaction; email, instant messaging, telephone.
	> > 
	> > 
	> >   The contact message directs Alice to the capture site. 
	> While this is
	> >   typically a Web site today the use of automated telephone 
	> attendant
	> >   sites via VOIP is rising.
	> > 
	> > 
	> >   k h
	> > 
	> 
	> 
	>