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'.
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-auth osafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth
|