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

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.

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".

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