W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: Request for review and consensus -- draft-hartman-webauth-phishing

From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Date: Thu, 11 Sep 2008 15:35:27 +0200
To: Lisa Dusseault <lisa@osafoundation.org>, HTTP Working Group <ietf-http-wg@w3.org>, Apps Discuss <discuss@ietf.org>
Message-ID: <20080911133527.GA13697@nic.fr>

On Wed, Sep 03, 2008 at 01:41:39PM -0700,
 Lisa Dusseault <lisa@osafoundation.org> wrote 
 a message of 39 lines which said:

> If you'd like to review it, please do.

I was skeptical at the origin of this work because phishing mitigation
is 50 % UI design and 50 % psychology, two domains where the IETF has
no expertise or legitimacy (which does not prevent some people to use
the fear of phishing for advancing their ideas, as we saw for the IDN
protocol).

But I find the draft quite good because it is modest, it stays in IETF
waters, network protocols. I agree with the general idea (using new
authentication protocols to reduce the incentive for phishing).

A few remarks:

Section 3, the sentence "As a consequence of this assumption, users
will likely be fooled by strings either in website names or
certificates that look visually similar but that are composed of
different code points." should be deleted. It is exactly the sort of
thing (psychology of users) that we should stay away from. Moreover,
it does not reflect the reality of phishing: very few phishers take
the trouble to fake the domain name (that's why the whole issue of
phishing for IDN is a red herring). Most of the phishing Web sites
have an unrelated domain name (smith.example.com) or even an IP
address. The few that try to fake the domain name use tricks like a
dash instead of a dot (secure-paypal.com) and do not rely on visual
confusability.

Section 4.5 says "Assuming that only certificates from trusted CAs are
accepted". I would delete it too. One of the big problems with X.509
is precisely that there is never an informed decision by the user to
trust or not a CA. The user typically blindly accepts what's in the
browser list of CA, list which was compiled on many criteria, trust
being only one of them.
Received on Thursday, 11 September 2008 13:36:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:54 GMT