RE: Secure Chrome and Secure MetaData

I saw a similar defocusing pressure at the TIPPI workshop.
 
Presenter shows plugin designed to explore the user interface issues:
 
        "What about key loggers", "what about a man in the middle attack", "no the real problem is the authentication credentials", "the phishing criminals will just go into selling plots of land in the Florida", and so on.
 
There are many problems here, when we are talking about digest algorithms we have an established vocabulary of terms, SHA-1 is not broken, it is subject to a compression collision attack but is still secure against the second pre-image attack. So when we are talking about S/MIME we say, no the SHA-1attacks do not compromise the use in that protocol but they are a sign we should start the transition process. 
 
What we need is a simple taxonomy of four or five terms (5 = 7-2) that we can use to refer to the various attacks. We choose to address one or at most two of those terms in this group. Everything else is out of scope.
 
Examples:
 
Platform Layer Attacks: OUT OF SCOPE
        
        Keyboard loggers, mouse click and screen capture trojans are all serious security issues. 
 
        Building platforms resistant to those attacks are the sole responsibility of Brian, Butler, Linus and Steve (surnames redacted for their own protection). It makes no sense for a standards working group to attempt to solve those problems. Preventing the circulation of malware is going to be the responsibility of the ISPs hosting the bots. 
 
Network Layer Attacks: OUT OF SCOPE
 
        We have several people in the group who are cryptographers and/or network security protocol designers. There is a place to discuss that work, this is not it. There is no shortage of forums that are developing authentication &ct. protocols. 
 
Trust Infrastructure Attacks: OUT OF SCOPE
 
        If we are going to stop phishing we are going to need a means of making sure that the site representing itself as Contoso bank on the net reall is the same corporation as the place where you opened the account abd handed over the check. This infrastructure is necessary, complex and I am currently sitting in the CA-Browser forum where we are discussing that exact problem.
 
User Interaction Attacks: IN SCOPE
 
        How does the browser communicate the security context to the user?
 
Chrome Attacks: IN SCOPE
 
        How does the browser ensure that the trusted path used to communicate the security context is trustworthy?
        
The title of this group is not 'the lone group that is going to stop the problem of phishing all by itself'. 

We have retrod the well trodden paths plenty of times. We have to assume that the groups that are dedicated to addressing those problems are going to deliver controls that are effective at an acceptable level.
 
At the moment the groups working on those problems are all saying 'we can stop the keylogger problem but what is the point if the social engineering attack is still open'.
 
 



________________________________

	From: public-usable-authentication-request@w3.org [mailto:public-usable-authentication-request@w3.org] On Behalf Of Mary Ellen Zurko
	Sent: Tuesday, June 20, 2006 3:29 PM
	To: public-usable-authentication@w3.org
	Subject: Secure Chrome and Secure MetaData
	
	

	If you're on this list and care at all about Secure Chrome and Secure MetaData, and about your colleagues who also care about Secure Chrome and Secure MetaData, you'll refrain from discussing other topics, even if you have the most brilliant insight in the world on them. 
	        Mez 
	
	Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
	IBM Lotus/WPLC Security Strategy and Architecture