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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]