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

From: Lisa Dusseault <[email-masked]>
Date: Wed, 3 Sep 2008 13:41:39 -0700

You may have seen this draft a year ago; Sam is back working on it and  
produced version -09 last month.

http://tools.ietf.org/html/draft-hartman-webauth-phishing-09

If you've reviewed it before, please take a look at the changes.  If  
you'd like to review it, please do.  I'm the shepherd for this draft,  
so comments can be sent to me, to Sam as author, to [email-masked] 
, or to the IETF general list as appropriate.

In addition to getting general input, I'd like to get a sense of  
whether we have consensus on a couple things.

a).  The statement including "IETF recommends", from section 1.1 of  
the draft:

    "In publishing this memo, the IETF recommends making available
    authentication mechanisms that meet the requirements outlined in
    Section 4 in HTTP user agents including web browsers.  It is hoped
    that these mechanisms will prove a useful step in fighting phishing.
    However this memo does not restrict work either in the IETF or any
    other organization.  In particular, new authentication efforts are
    not bound to meet the requirements posed in this memo unless the
    charter for those efforts chooses to make these binding  
requirements.
    Less formally, the IETF presents this memo as an option to pursue
    while acknowledging that there may be other promising paths both now
    and in the future."

b) Whether the document should require mutual authentication (section  
4.4).

Thanks,
Lisa D.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 05 Sep 2008 03:26:10 +1200

Lisa Dusseault <[email-masked]> writes:

>[...]
>b) Whether the document should require mutual authentication (section 4.4).

Yes, absolutely!  The whole reason why phishing works is that the site is
never authenticated, without mutual auth (and specifically strong mutual auth,
e.g. some form of cryptographic challenge-response mechanism rather than the
pretend-auth of "do you recognise this image?" that some US banks have
adopted) you've not really achieving much.

Peter.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Sep 2008 15:35:27 +0200

On Wed, Sep 03, 2008 at 01:41:39PM -0700,
 Lisa Dusseault <[email-masked]> 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.