New draft on anti-phishing requirements

On Mon, May 22, 2006 at 12:14:51PM -0400, Robert Sayre
wrote:
> On 5/22/06, Eric Rescorla <ekrnetworkresonance.com>
wrote:
> >1. This is not principally a protocol problem but
rather a UI problem.
> >  The protocol problems are generally well
understood. If the UI
> >  problems are solved, nearly any protocol will
work. In particular,
> >  there have been a number of published designs [1]
[2] that have mostly
> >  adequate (though not perfect) protocols, though
without complete
> >  solutions to the UI problem.
> 
> One aspect of Sam's document that concerned me was the
section on
> possible UI solutions. The requirements around spoofing
seem directly
> opposed to the branding and usage patterns that web
authors require.
> HTTP authentication currently presents a modal dialog
with no design
> control, and this is a significant reason most sites
opt for form
> controls.

Sam wants to put control over the UI in the web site's
authors' hands.

But he wants this UI tied intimately to a new browser
function that is
tied intimately to authentication protocols.

> Roy has previously mentioned that 401 Unauthorized
responses should be
> displayed to the user. This would allow a site to embed
a new type of
> form control for authentication purposes... but as I
mentioned above,
> this intermingling could increase the risk of spoofing.

As Sam says: the browser must change.  There are problems we
cannot
solve using nothing more than HTML, HTTP/HTTPS and existing
browser
functionality.

Nico
-- 
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

>>>>> "Nicolas" == Nicolas
Williams <Nicolas.Williamssun.com> writes:

    Nicolas> On Mon, May 22, 2006 at 12:14:51PM -0400,
Robert Sayre
    Nicolas> wrote:
    >> On 5/22/06, Eric Rescorla <ekrnetworkresonance.com> wrote:
    >> >1. This is not principally a protocol
problem but rather a UI
    >> problem.  > The protocol problems are
generally well
    >> understood. If the UI > problems are solved,
nearly any
    >> protocol will work. In particular, > there
have been a number
    >> of published designs [1] [2] that have mostly
> adequate
    >> (though not perfect) protocols, though without
complete >
    >> solutions to the UI problem.
    >> 
    >> One aspect of Sam's document that concerned me
was the section
    >> on possible UI solutions. The requirements
around spoofing seem
    >> directly opposed to the branding and usage
patterns that web
    >> authors require.  HTTP authentication currently
presents a
    >> modal dialog with no design control, and this
is a significant
    >> reason most sites opt for form controls.

    Nicolas> Sam wants to put control over the UI in the
web site's
    Nicolas> authors' hands.

    Nicolas> But he wants this UI tied intimately to a
new browser
    Nicolas> function that is tied intimately to
authentication
    Nicolas> protocols.

    >> Roy has previously mentio
Exactly.

I don't think we want today's http authentication
dialogues.

Really. the secure UI could be as simple as any of the
following:

* You choose what icon is used for bullets in a secure
password form
  control when you create your account on a computer.  The
standard
  bullet is used if it is a normal HTML control; the one you
selected
  is used if it is a control that will make the password
available
  only to the trusted authentication part of the browser.


*  You have a keystroke and mouse action that will hide
non-trusted components of the UI.

I'm not a UI designer.  I don't know how to come up with a
UI that
maximizes the probability that the user will actually notice
when they
are typing a password into the wrong place.  I'm just
trying to
demonstrate that we need not have something as clunky as
current http
authentication dialogues.
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

On 5/22/06, Nicolas Williams <Nicolas.Williamssun.com> wrote:
>
> As Sam says: the browser must change.

Sure, and I suspect almost all browser vendors are willing
to do that,
but I think better security is an insufficient motivator for
web
authors. The requirement for mutual authentication was
interesting to
me. Groups extending Web formats and APIs[1] often encounter
situations where a slightly elevated trust level for certain
scripts
would be useful.

Offering a carrot in the form of an extended JavaScript API
for
authenticated scripts would probably accelerate deployment
of these
new efforts.

[1] http://www.w3.org/2006
/webapi/

-- 

Robert Sayre
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

On Mon, May 22, 2006 at 02:45:45PM -0400, Robert Sayre
wrote:
> On 5/22/06, Nicolas Williams <Nicolas.Williamssun.com> wrote:
> >
> >As Sam says: the browser must change.
> 
> Sure, and I suspect almost all browser vendors are
willing to do that,
> but I think better security is an insufficient
motivator for web
> authors. The requirement for mutual authentication was
interesting to
> me. Groups extending Web formats and APIs[1] often
encounter
> situations where a slightly elevated trust level for
certain scripts
> would be useful.
> 
> Offering a carrot in the form of an extended JavaScript
API for
> authenticated scripts would probably accelerate
deployment of these
> new efforts.

Call it an "extended JavaScript API" or
something else, it doesn't
matter what it is called, as long as it is:

a) a browser function
b) that can be invoked from an HTML UI element
c) and which ties into the actual protocol and
authentication
   mechanism(s) used on the wire

Again, you can call the HTML UI element a form, or something
else.

It is a carrot.  Those who don't want to use it won't have
to.

But why not use it if it's available?

That this all has to live in the browser should be no
obstacle.  That
web site authors have to detect its presence in their client
browsers
and choose to use it should be no obstacle either.

Nico
-- 
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth