On Sep 9, 2007, at 5:37 PM, Iljitsch van Beijnum wrote:
On 8-sep-2007, at 20:09, Alexey Melnikov wrote:
This message is trying to summarize recent discussions on draft-
hartman-webauth-phishing-05.txt.
Several people voiced their support for the document (on IETF
mailing list and in various other off-list discussions). Ekr
doesn't think that the document should be published in the current
form and he has some good technical points that need to be
addressed. At least one more revision is needed to addressed
recent comments from Ekr and SecDir review.
Here's an outsider review.
What's an Ekr, btw?
I really dislike the use of "fishing" with creative spelling in a
document prepared for an international standards organization. The
world certainly doesn't need more words that sound the same and
differ in meaning only by the way they're written, and I'm not sure
how prevalent this terminology is outside the US and/or the English
speaking world. Please come up with something more descriptive.
I tend to rely on Dictionaries to sort these things out - from
Dictionary.com
-----
Webster's New Millennium™ Dictionary of English - Cite This Source
Main Entry:
phishing
Part of Speech:
n
Definition:
the practice of luring unsuspecting Internet users to a fake Web site
by using authentic-looking email with the real organization's logo,
in an attempt to steal passwords, financial or personal information,
or introduce a virus attack; the creation of a Web site replica for
fooling unsuspecting Internet users into submitting personal or
financial information or passwords
Example:
1996; as in 'fish' for users
Etymology:
phish, v; phisher, n
Webster's New Millennium™ Dictionary of English, Preview Edition (v
0.9.7)
Copyright © 2003-2007 Lexico Publishing Group, LLC
-----
So, my personal opinion is that it would be OK with an definition.
Regards
Marshall
During the reading of this document, it occurred to me that HTTP
digest authentication (RFC 2617) rather than the widely used
practice of having security credentials be typed into an HTTP form
would achieve 90% of the requirements all by itself. (More or less
the same thing for S/MIME in mail.) The main part that's missing
there is protection against a man in the middle. Obviously TLS goes
through great pains to avoid men in the middle, but the document
has no trouble throwing that out of the window:
The attacker can also spoof trust markers
such as the security lock, URL bar and other parts of the
browser UI.
And:
Users do not typically understand
certificates and cannot make informed decisions about whether the
subject name in a certificate corresponds to the entity they are
attempting to communicate with. 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.
Although I agree that a system that can work even under these
assumptions would be great, I think it's harmful to adopt them in
this way, 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
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.
Last but not least, I'm guessing that "ben Laurie" is actually "Ben
Laurie".
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf