Re: [saag] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)

der Mouse <mouse@Rodents.Montreal.QC.CA> Mon, 10 September 2007 14:27 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IUkEE-0008Tt-EC; Mon, 10 Sep 2007 10:27:06 -0400
Received: from discuss by with local (Exim 4.43) id 1IUkED-0008Ta-Cw for; Mon, 10 Sep 2007 10:27:05 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IUkED-0008TR-2p for; Mon, 10 Sep 2007 10:27:05 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IUkEB-00079n-EO for; Mon, 10 Sep 2007 10:27:04 -0400
Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA03299; Mon, 10 Sep 2007 10:26:53 -0400 (EDT)
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Message-Id: <200709101426.KAA03299@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
Date: Mon, 10 Sep 2007 10:14:07 -0400 (EDT)
Subject: Re: [saag] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
In-Reply-To: <>
References: <> <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> I really dislike the use of "fishing" with creative spelling in a
> document prepared for an international standards organization.

Perhaps unfortunately, that is *the* word for the behaviour in
question, at least in English.  It was not invented for the draft, and
"com[ing] up with something [else]" would be *less* descriptive and
would render the document cryptic to the people who's been working
against phishing for years.  Perhaps it's a bad word to use in other
languages, but that should be addressed by the translator(s) in
question, not by mangling the original.

> [...], because it sends a number of very bad messages:

> - it's ok for browser vendors to play fast and loose with security
>   related UI elements such as the lock icon and the URL bar (i.e.,
>   have them controlled by the remote server)

> - it's ok for domain vendors to sell domains that use IDN trickery

> - it's ok for certificate vendors to sell certificates that seem to
>   be tied to some known entity but are in reality tied to a different
>   entity

It appears they *are* OK, pragmatically; at least, the first and third
- and quite possibly the second, for all I know - are continuing with
no apparent backlash.

> All of these are unacceptable and we as users of these services,
> community members, engineers and IETF members should do what we can
> to make sure that they don't happen.

Ideally, yes.  Let me know when you manage to get users to drop every
major Web browser and every major cert vendor because they're insecure
against these attacks - never mind when you find users competent to
even understand the issue, much less evaluate Web browsers and cert
vendors in these regards.

In the meantime, I see nothing wrong (and much right) with a draft that
addresses this problem - or at least tries to - in the world as it is,
rather than the world as you, me, and a tiny minority of other people
would like it to be.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B