Subject: [dix] RE: [Ietf-http-auth] Notes on Web authentication enhancements

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 20 Jun 2006 14:34:00 -0700

I just sent this message to the W3C pre-WG mailing list. I think the message is equally applicable here only any new group/groups should either identify a different part of the problem to address or they should coordinate with the W3C group so that the groups avoid going off to hunt the same bear. When that happens the most likely outcome is the groups end up shooting each other instead of the bear.

I was at the TIPPI workshop yesterday which showed a similar tendency to become defocused as people became confused about the question of what problem was being addressed in a presentation.
 
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'.

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Jun 2006 10:16:46 -0400

Phil, I think I agree with the importance of having definitions.

I find it amusing that I cannot understand what you mean by user
interaction attacks and chrome attacks; I cannot tell what you would
consider within those definitions and what you would consider outside
those definitions.

I also don't know where you consider the boundary for network layer
issues; I may or may not agree with you that should be out of scope.