W3C home > Mailing lists > Public > public-usable-authentication@w3.org > June 2006

Re: Secure Chrome and Secure MetaData

From: Drew Dean <ddean@yahoo-inc.com>
Date: Tue, 20 Jun 2006 14:30:15 -0700
Message-Id: <81893D9E-BD96-48FB-A4D9-48F918519391@yahoo-inc.com>
Cc: "Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>, <public-usable-authentication@w3.org>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>

To follow up on Phil and Mary's points:

I find it rather interesting that there's been no discussion of the  
Compartmented Mode Workstations (CMW) of the 1980s-1990s.  While they  
aren't a shining example of success, unambiguously displaying the  
security label of a window is exactly the "secure chrome" problem.   
If we don't study history, we'll be condemned to repeat it....

I mostly, but not entirely, agree with Phil's ruling platform attacks  
out of scope.  I agree that solving that problem isn't our problem,  
but think that we can reasonably specify requirements on the platform  
at and below us (i.e., browser & underlying OS) to support a trusted  
path of some sort.  The details, however, should be out of scope --  
and may/probably be implementation dependent, so there's not much to  
standardize.

Drew

On Jun 20, 2006, at 2:14 PM, Hallam-Baker, Phillip wrote:

> 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
Received on Wednesday, 21 June 2006 01:04:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:15 UTC