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".
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf