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

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 mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

Received on Monday, 10 September 2007 08:39:07 UTC