Subject: Re: [Ietf-http-auth] Request for review and consensus -- draft-hartman-webauth-phishing
From: SM <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Date: Sat, 20 Sep 2008 01:52:30 -0700
List-Id: ietf-http-auth.osafoundation.org

Hi Tom,
At 11:02 18-09-2008, Tom Yu wrote:
>I have repeatedly heard, from various people in the IETF, statements
>to the effect of "it's a user interface design consideration, so we
>don't have to worry about it".  Your statement above might not be an
>expression of this sentiment, but I think the point is worth
>addressing.

We do have to worry and care about user interface considerations.  I 
was focusing on what part of the problem the IETF may be able to 
address and which part may be better suited for the W3C.

>The IETF should certainly care about user interface design, but in a
>very particular way: the protocols that the IETF designs place
>constraints on user interface designers, and these constraints can
>drive user interface design in ways that dramatically affect the
>security and quality of the end user experience.

Agreed.  That's why it's better to work with user interface designers 
to find out the constraints the protocol places on their work and how 
it affect the security of the end user experience.  It's all part of the chain.

Regards,
-sm 

Date: Fri, 19 Sep 2008 18:34:34 -0700
From: Chris Newman <[email-masked]>
Subject: Re: [Ietf-http-auth] Request for review and consensus -- draft-hartman-webauth-phishing
Sender: [email-masked]
To: Tom Yu <[email-masked]>, SM <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>

Well said!

I'll add that I believe several IETF protocols are less successful than 
they could be due to our failure to consider and/or address the user 
interface constraints created by our protocols, and our failure to 
communicate advice that could be used to create better user interfaces.

		- Chris

--On September 18, 2008 14:02:38 -0400 Tom Yu <[email-masked]> wrote:

> SM <[email-masked]> writes:
>
>> At 09:01 09-09-2008, Tom Yu wrote:
>>>     "We assume that users wish to protect themselves, but are willing
>>>     to expend only limited effort to combat phishing; they will avoid
>>>     an interface if they find it too complicated.  This can result in
>>>     the user preferring a simpler insecure interface to a more complex
>>>     but more secure one.  Alternatively, a user more fully informed of
>>>     the risks may abandon any effort to access a service if the choice
>>>     is between using a complex, secure interface and using a simple
>>>     but known-to-be-insecure interface."
>>
>> That's a good summary of the problem from a user angle.  It's a user
>> interface design consideration.
>
> I have repeatedly heard, from various people in the IETF, statements
> to the effect of "it's a user interface design consideration, so we
> don't have to worry about it".  Your statement above might not be an
> expression of this sentiment, but I think the point is worth
> addressing.
>
> The IETF should certainly care about user interface design, but in a
> very particular way: the protocols that the IETF designs place
> constraints on user interface designers, and these constraints can
> drive user interface design in ways that dramatically affect the
> security and quality of the end user experience.
>
> By their very nature, user interfaces involve the user interacting
> with or interfacing with something.  I will grant that presentation
> details of a user interface, such as graphical layout, are not the
> business of the IETF.  Protocol design affects what information is
> available to a user through a user interface.  It also affects the
> relationships among those pieces of information in terms of time,
> space, and dependencies.
>
> For these reasons, I think that the IETF should pay careful attention
> to how protocol design decisions affect user interface design.
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>

To: SM <[email-masked]>
Subject: Re: [Ietf-http-auth] Request for review and consensus -- draft-hartman-webauth-phishing
From: Tom Yu <[email-masked]>
Date: Thu, 18 Sep 2008 14:02:38 -0400
Lines: 37
Cc: [email-masked], Sam Hartman <[email-masked]>

SM <[email-masked]> writes:

> At 09:01 09-09-2008, Tom Yu wrote:
>>     "We assume that users wish to protect themselves, but are willing
>>     to expend only limited effort to combat phishing; they will avoid
>>     an interface if they find it too complicated.  This can result in
>>     the user preferring a simpler insecure interface to a more complex
>>     but more secure one.  Alternatively, a user more fully informed of
>>     the risks may abandon any effort to access a service if the choice
>>     is between using a complex, secure interface and using a simple
>>     but known-to-be-insecure interface."
>
> That's a good summary of the problem from a user angle.  It's a user
> interface design consideration.

I have repeatedly heard, from various people in the IETF, statements
to the effect of "it's a user interface design consideration, so we
don't have to worry about it".  Your statement above might not be an
expression of this sentiment, but I think the point is worth
addressing.

The IETF should certainly care about user interface design, but in a
very particular way: the protocols that the IETF designs place
constraints on user interface designers, and these constraints can
drive user interface design in ways that dramatically affect the
security and quality of the end user experience.

By their very nature, user interfaces involve the user interacting
with or interfacing with something.  I will grant that presentation
details of a user interface, such as graphical layout, are not the
business of the IETF.  Protocol design affects what information is
available to a user through a user interface.  It also affects the
relationships among those pieces of information in terms of time,
space, and dependencies.

For these reasons, I think that the IETF should pay careful attention
to how protocol design decisions affect user interface design.

Date: Tue, 09 Sep 2008 17:20:46 -0700
To: Sam Hartman <[email-masked]>
From: SM <[email-masked]>
Subject: Re: [Ietf-http-auth] Request for review and consensus --    draft-hartman-webauth-phishing
Cc: [email-masked]

Hi Sam,
At 06:05 09-09-2008, Sam Hartman wrote:
>One of my goals in section 1.1 was to avoid doing that.  Assuming the
>IETF had consensus behind the text in section 1.1, how would these
>requirements constrain other paths?

Because it can be used as a set of requirements.

May I ask why it is important that this document becomes an IETF 
recommendation?

>Would you be happier with  "We assume that users are interested in 
>combatting phishing, but cannot be expected to learn the details of 
>security protocols, certification practices, and the like."

You could drop the first sentence.  You already explained the 
problems for users in the rest of that paragraph.

At 09:01 09-09-2008, Tom Yu wrote:
>     "We assume that users wish to protect themselves, but are willing
>     to expend only limited effort to combat phishing; they will avoid
>     an interface if they find it too complicated.  This can result in
>     the user preferring a simpler insecure interface to a more complex
>     but more secure one.  Alternatively, a user more fully informed of
>     the risks may abandon any effort to access a service if the choice
>     is between using a complex, secure interface and using a simple
>     but known-to-be-insecure interface."

That's a good summary of the problem from a user angle.  It's a user 
interface design consideration.

Regards,
-sm 

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] [Bringing OAuth to the IETF]
Date: Tue, 9 Sep 2008 12:39:17 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "RL 'Bob' Morgan" <[email-masked]>, "HTTP authentication list" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C912B3.CEF41B6C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes, very interesting indeed. I like the concept of a valet key.

________________________________

From: [email-masked] on behalf of RL 'Bob' =
Morgan
Sent: Tue 9/9/2008 12:52 PM
To: HTTP authentication list
Subject: [Ietf-http-auth] [Bringing OAuth to the IETF]

I thought folks here might be interested in this.  See http://oauth.net/
for OAuth info if you haven't heard about it before.  Among other things
OAuth specifies a new HTTP Authorization scheme.

  - RL "Bob"

---------- Forwarded message ----------
Date: Mon, 8 Sep 2008 17:40:05 -0700
From: eran <[email-masked]>
Reply-To: [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: [oauth] Bringing OAuth to the IETF

We are almost a year away from the the OAuth Core 1.0 final draft. It =
has
been a very successful year for the protocol and at the summit we had
many great suggestions and idea on where to take the spec and the
community. Over the past few months I had a couple of interesting talks
with members of the IETF with regard to OAuth. The ideas range from
proposing OAuth as an IEFT standard to seeking official application
review of the protocol from HTTP and web experts, to simply publishing
OAuth as an informational RFC. I think there is great value in much of
the suggested range.

In recent years, there have been multiple attempts at the IETF to create
some standard around HTTP authorization and so far very little progress
has been made. While OAuth is not yet at a standard level, it is by far
the most visible and successful proposal on how this could be done.

The first step to any valuable interaction with the IETF is to publish
the core spec as an internet draft. This should be pretty easy given the
tools we used to write the spec. In addition to publishing OAuth as an
unassigned draft (means no upfront declaration of which IETF track this
will belong to), I would like to schedule a BOF at the next IETF meeting
(Fall 2008 - 73rd IETF, November 16-21, 2008, Host: Google, Location:
Minneapolis, MN, USA).

Moving forward there are a couple of open questions we need to consider.
One is which names to put on the draft, given that the IETF editors tend
to limit it to 5 authors or only list editors. The best example for this
is the ATOM spec which started very much like OAuth in an open community
and later moved into the IETF. The spec has two named editors and all
other contributors are listed in the spec itself. My proposal is to put
Blaine Cook's name as author and mine as editor on top with everyone =
else
listed in the spec under a Contributors section. This might sound like a
silly thing to discuss but I rather make this a community decision.

The other question is where to hold such IETF/OAuth discussions online
given that we already have a healthy community right here. I think we =
can
wait to see where things go before we need to address that but your =
views
would be greatly appreciated.

EHL
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google =
Groups
"OAuth" group.
To post to this group, send email to [email-masked]
To unsubscribe from this group, send email to
[email-masked]
For more options, visit this group at
http://groups.google.com/group/oauth?hl=3Den
-~----------~----~----~----~------~----~------~--~---

------_=_NextPart_001_01C912B3.CEF41B6C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>[Ietf-http-auth] [Bringing OAuth to the =
IETF]</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6000.16711" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText37633 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Yes, very =
interesting indeed. I like the concept of a valet key.</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked] on behalf of RL 'Bob' =
Morgan<BR><B>Sent:</B> Tue 9/9/2008 12:52 PM<BR><B>To:</B> HTTP =
authentication list<BR><B>Subject:</B> [Ietf-http-auth] [Bringing OAuth =
to the IETF]<BR></FONT><BR></DIV>=0A=
<DIV><BR>=0A=
<P><FONT size=3D2>I thought folks here might be interested in =
this.&nbsp; See <A =
href=3D"http://oauth.net/">http://oauth.net/</A><BR>for OAuth info if =
you haven't heard about it before.&nbsp; Among other things<BR>OAuth =
specifies a new HTTP Authorization scheme.<BR><BR>&nbsp; - RL =
"Bob"<BR><BR>---------- Forwarded message ----------<BR>Date: Mon, 8 Sep =
2008 17:40:05 -0700<BR>From: eran =
&lt;[email-masked]&gt;<BR>Reply-To: [email-masked]<BR>To: =
"[email-masked]" &lt;[email-masked]&gt;<BR>Subject: =
[oauth] Bringing OAuth to the IETF<BR><BR>We are almost a year away from =
the the OAuth Core 1.0 final draft. It has<BR>been a very successful =
year for the protocol and at the summit we had<BR>many great suggestions =
and idea on where to take the spec and the<BR>community. Over the past =
few months I had a couple of interesting talks<BR>with members of the =
IETF with regard to OAuth. The ideas range from<BR>proposing OAuth as an =
IEFT standard to seeking official application<BR>review of the protocol =
from HTTP and web experts, to simply publishing<BR>OAuth as an =
informational RFC. I think there is great value in much of<BR>the =
suggested range.<BR><BR>In recent years, there have been multiple =
attempts at the IETF to create<BR>some standard around HTTP =
authorization and so far very little progress<BR>has been made. While =
OAuth is not yet at a standard level, it is by far<BR>the most visible =
and successful proposal on how this could be done.<BR><BR>The first step =
to any valuable interaction with the IETF is to publish<BR>the core spec =
as an internet draft. This should be pretty easy given the<BR>tools we =
used to write the spec. In addition to publishing OAuth as =
an<BR>unassigned draft (means no upfront declaration of which IETF track =
this<BR>will belong to), I would like to schedule a BOF at the next IETF =
meeting<BR>(Fall 2008 - 73rd IETF, November 16-21, 2008, Host: Google, =
Location:<BR>Minneapolis, MN, USA).<BR><BR>Moving forward there are a =
couple of open questions we need to consider.<BR>One is which names to =
put on the draft, given that the IETF editors tend<BR>to limit it to 5 =
authors or only list editors. The best example for this<BR>is the ATOM =
spec which started very much like OAuth in an open community<BR>and =
later moved into the IETF. The spec has two named editors and =
all<BR>other contributors are listed in the spec itself. My proposal is =
to put<BR>Blaine Cook&#8217;s name as author and mine as editor on top =
with everyone else<BR>listed in the spec under a Contributors section. =
This might sound like a<BR>silly thing to discuss but I rather make this =
a community decision.<BR><BR>The other question is where to hold such =
IETF/OAuth discussions online<BR>given that we already have a healthy =
community right here. I think we can<BR>wait to see where things go =
before we need to address that but your views<BR>would be greatly =
appreciated.<BR><BR>EHL<BR>--~--~---------~--~----~------------~-------~-=
-~----~<BR>You received this message because you are subscribed to the =
Google Groups<BR>"OAuth" group.<BR>To post to this group, send email to =
[email-masked]<BR>To unsubscribe from this group, send email =
to<BR>[email-masked]<BR>For more options, visit this =
group at<BR><A =
href=3D"http://groups.google.com/group/oauth?hl=3Den">http://groups.googl=
e.com/group/oauth?hl=3Den</A><BR>-~----------~----~----~----~------~----~=
------~--~---<BR><BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C912B3.CEF41B6C--

From: Sam Hartman <[email-masked]>
To: Tom Yu <[email-masked]>
Date: Tue, 09 Sep 2008 13:22:32 -0400
Cc: [email-masked]
Subject: [Ietf-http-auth] Assumptions about user motivations

>>>>> "Tom" == Tom Yu <[email-masked]> writes:

    Tom> I think your proposed change above is largely redundant with
    Tom> the rest of the paragraph that follows it in the I-D.  I
    Tom> think it is more useful to say:

    Tom>     "We assume that users wish to protect themselves, but are
    Tom> willing to expend only limited effort to combat phishing;
    Tom> they will avoid an interface if they find it too complicated.
    Tom> This can result in the user preferring a simpler insecure
    Tom> interface to a more complex but more secure one.
    Tom> Alternatively, a user more fully informed of the risks may
    Tom> abandon any effort to access a service if the choice is
    Tom> between using a complex, secure interface and using a simple
    Tom> but known-to-be-insecure interface."

I like this text.
I would also like to hear other versions that attempt to better condince this.

Date: Tue, 9 Sep 2008 09:52:42 -0700 (PDT)
From: "RL 'Bob' Morgan" <[email-masked]>
To: HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] [Bringing OAuth to the IETF]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-1245624855-1220979182=:3067
Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

I thought folks here might be interested in this.  See http://oauth.net/ 
for OAuth info if you haven't heard about it before.  Among other things 
OAuth specifies a new HTTP Authorization scheme.

  - RL "Bob"

---------- Forwarded message ----------
Date: Mon, 8 Sep 2008 17:40:05 -0700
From: eran <[email-masked]>
Reply-To: [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: [oauth] Bringing OAuth to the IETF

We are almost a year away from the the OAuth Core 1.0 final draft. It has
been a very successful year for the protocol and at the summit we had
many great suggestions and idea on where to take the spec and the
community. Over the past few months I had a couple of interesting talks
with members of the IETF with regard to OAuth. The ideas range from
proposing OAuth as an IEFT standard to seeking official application
review of the protocol from HTTP and web experts, to simply publishing
OAuth as an informational RFC. I think there is great value in much of
the suggested range.

In recent years, there have been multiple attempts at the IETF to create
some standard around HTTP authorization and so far very little progress
has been made. While OAuth is not yet at a standard level, it is by far
the most visible and successful proposal on how this could be done.

The first step to any valuable interaction with the IETF is to publish
the core spec as an internet draft. This should be pretty easy given the
tools we used to write the spec. In addition to publishing OAuth as an
unassigned draft (means no upfront declaration of which IETF track this
will belong to), I would like to schedule a BOF at the next IETF meeting
(Fall 2008 - 73rd IETF, November 16-21, 2008, Host: Google, Location:
Minneapolis, MN, USA).

Moving forward there are a couple of open questions we need to consider.
One is which names to put on the draft, given that the IETF editors tend
to limit it to 5 authors or only list editors. The best example for this
is the ATOM spec which started very much like OAuth in an open community
and later moved into the IETF. The spec has two named editors and all
other contributors are listed in the spec itself. My proposal is to put
Blaine Cook’s name as author and mine as editor on top with everyone else
listed in the spec under a Contributors section. This might sound like a
silly thing to discuss but I rather make this a community decision.

The other question is where to hold such IETF/OAuth discussions online
given that we already have a healthy community right here. I think we can
wait to see where things go before we need to address that but your views
would be greatly appreciated.

EHL
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to [email-masked]
To unsubscribe from this group, send email to
[email-masked]
For more options, visit this group at
http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---

--8323328-1245624855-1220979182=:3067--

To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] Request for review and consensus -- draft-hartman-webauth-phishing
From: Tom Yu <[email-masked]>
Date: Tue, 09 Sep 2008 12:01:09 -0400
Lines: 40
Cc: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "SM" == SM  <[email-masked]> writes:
>
>     SM> Quoting a sentence from Section 3:
>
>     SM>    "We assume that users have limited motivation to combat
>     SM> phishing."
>
> Would you be happier with "We assume that users are interested in
> combatting phishing, but cannot be expected to learn the details of
> security protocols, certification practices, and the like."

I think your proposed change above is largely redundant with the rest
of the paragraph that follows it in the I-D.  I think it is more
useful to say:

    "We assume that users wish to protect themselves, but are willing
    to expend only limited effort to combat phishing; they will avoid
    an interface if they find it too complicated.  This can result in
    the user preferring a simpler insecure interface to a more complex
    but more secure one.  Alternatively, a user more fully informed of
    the risks may abandon any effort to access a service if the choice
    is between using a complex, secure interface and using a simple
    but known-to-be-insecure interface."

I know that my suggested text should be condensed more, but I'm trying
to see if that more effectively conveys the intended meaning.

The paragraph in its original form appears to encompass two related
concepts:

* We cannot expect users to be security experts.

* We cannot expect users to expend significant effort to protect
  themselves against risks they only poorly understand.

A complex interface that requires the user to make a security judgment
is doubly flawed, in my opinion, but this appears to be the experience
of Web browsing today.

From: Sam Hartman <[email-masked]>
To: SM <[email-masked]>
Subject: Re: [Ietf-http-auth] Request for review and consensus -- draft-hartman-webauth-phishing
Date: Tue, 09 Sep 2008 09:05:27 -0400
Cc: [email-masked]

>>>>> "SM" == SM  <[email-masked]> writes:

    SM> Hi Sam,
    SM> It may be difficult to gain IETF consensus on such
    SM> requirements if the document does not take into account
    SM> ongoing work such as draft-oiwa-http-mutualauth-03.  

I'm familiar with that work.  I just reviewed that draft again; it
definitely seems like that protocol could be deployed in a manner that
is consistent with these requirements.

    SM> By coming
    SM> up with a set of requirements at this stage, we may be
    SM> constraining "other promising paths".

One of my goals in section 1.1 was to avoid doing that.  Assuming the
IETF had consensus behind the text in section 1.1, how would these
requirements constrain other paths?

(as an aside, I personally believe that these would be great
requirements for draft-oiwa-http-mutualauth-03: they would be easy to meet and I believe would if not already met improve the protocol.)
    SM> whereas the user interface questions are better suited for the
    SM> W3C.  
I do agree that specifics of UI should be handled through the W3C.  I
think that details that affect the security of the protocol, such as
requiring that the UI distinguish (in some manner) password fields
that will be sent over the net using basic from those that will be
sent using some secure protocol are within the IETF's scope.

    SM> Quoting a sentence from Section 3:

    SM>    "We assume that users have limited motivation to combat
    SM> phishing."

Would you be happier with  "We assume that users are interested in combatting phishing, but cannot be expected to learn the details of security protocols, certification practices, and the like."

The goal of the existing sentence is to make it clear that asking
use.users to understand Unicode encoding issues, understand detailed
information about what is validated in a certificate etc, is not
appropriate.

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Date: Tue, 09 Sep 2008 08:48:48 -0400
Cc: [email-masked], [email-masked]
Subject: [Ietf-http-auth] Re: Request for review and consensus -- draft-hartman-webauth-phishing

Simon, can I get you to analyze what position the IETF should take on
these issues--what form of consensus we're looking for.

For my part, it doesn't make sense to pursue this within the IETF
context--responding to feedback, trying to get a draft that everyone
is happy with--if the IETF is going to take no position.

I agree we need to have a discussion about status.  But first, I'd
like to separate the discussion of what we're getting the IETF to
agree on.

Would you support the IETF making the statement is section 1.1?  If
not, what would you support, or what changes could we make to get to a
point where you would support the statement in section 1.1.

Date: Mon, 08 Sep 2008 15:00:20 -0700
To: Sam Hartman <[email-masked]>
From: SM <[email-masked]>
Subject: Re: [Ietf-http-auth] Request for review and consensus --   draft-hartman-webauth-phishing
Cc: [email-masked]

Hi Sam,
At 11:28 08-09-2008, Sam Hartman wrote:
>Can I get you to focus on what we want the ietf consensus to be 
>rather than on how to accomplish that?

Yes, we can.  Most of us would agree that phishing is a problem and 
something has to be done about it.  As such, your I-D is a step in 
the right direction.  In Section 1, it is mentioned that:

   "The requirements presented in this memo are intended to be useful to
    browser designers, designers of other HTTP applications and designers
    of future HTTP authentication mechanisms."

It may be difficult to gain IETF consensus on such requirements if 
the document does not take into account ongoing work such as 
draft-oiwa-http-mutualauth-03.  By coming up with a set of 
requirements at this stage, we may be constraining "other promising paths".

>I agree that we'll need to have a discussion of  how  to accomplish 
>that.  I think it is better to have a discussion of what we're 
>accomplishing though.

The document describes a threat model, then gets in protocol and user 
interface issues.  What we are accomplishing is mixing the two sides 
of the issue.

>Can I get you to ignore the intended status, review section 1.1 and
>the rest of the draft and comment on whether you think that would be a
>good position for the IETF to take on this issue, and if not, what
>position the IETF should take?

1. Does the work fall under the purview of the IETF?

2. Is the IETF in a position to solve the problem?

3. Is there interest within the IETF to work on a solution?

In my opinion, the IETF could tackle the protocol questions whereas 
the user interface questions are better suited for the W3C.  As we 
are discussing about requirements, it may be better to get this done 
through a Working Group effort.  If the community believes that the 
answers to the above questions are yes, then I would say "take on the 
issue".  Otherwise, we can settle for "the IETF takes no position".

Quoting a sentence from Section 3:

    "We assume that users have limited motivation to combat phishing."

I beg to differ.  That sounds like the users do not care about 
phishing.  Some users have the motivation but they don't know how to 
do it.  In a nutshell, we have failed in providing them with adequate 
tools to detect phishing attempts.

>No, I believe this ID makes no normative statement about how a user
>interface should be constructed.  It does make statements about what
>the protocol requires of the user interface at a very abstract
>level--well within what I've seen from other standards.

In Section 4.1:

   "The web authentication solution MUST support the password user
    interface and MUST be secure even when the password interface is
    commonly used."

I don't see how we can set a requirement level for a password user 
interface.  What we can do is to provide "hooks" into the system so 
as to interact with it through an API.

   "A solution to these requirements MUST also support smart cards and
    other authentication solutions."
Again, I don't see why smart cards is a MUST.

Regards,
-sm

From: Sam Hartman <[email-masked]>
To: SM <[email-masked]>
Subject: Re: [Ietf-http-auth] Request for review and consensus -- draft-hartman-webauth-phishing
Date: Mon, 08 Sep 2008 14:28:40 -0400
Cc: [email-masked]

>>>>> "SM" == SM  <[email-masked]> writes:

    SM> RFC 2606 mentions that an "Informational" specification is
    SM> published for the general information of the Internet
    SM> community, and does not represent an Internet community
    SM> consensus or recommendation.  Section 1.1 of the I-D is at
    SM> odds with that.  I suggest either reviewing the intended
    SM> status of the I-D or changing that paragraph.

Can I get you to focus on what we want the ietf consensus to be rather than on how to accomplish that?
I agree that we'll need to have a discussion of  how  to accomplish that.  I think it is better to have a discussion of what we're accomplishing though.

Can I get you to ignore the intended status, review section 1.1 and
the rest of the draft and comment on whether you think that would be a
good position for the IETF to take on this issue, and if not, what
position the IETF should take?

    SM> Is this I-D getting into user interface guidelines?  If so,
    SM> it's not standard-track material.

No, I believe this ID makes no normative statement about how a user
interface should be constructed.  It does make statements about what
the protocol requires of the user interface at a very abstract
level--well within what I've seen from other standards.

Date: Mon, 08 Sep 2008 10:58:01 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: [Ietf-http-auth] Request for review and consensus -- draft-hartman-webauth-phishing
Cc: Sam Hartman <[email-masked]>

At 13:41 03-09-2008, Lisa Dusseault wrote:
>You may have seen this draft a year ago; Sam is back working on it and
>produced version -09 last month.
>
>http://tools.ietf.org/html/draft-hartman-webauth-phishing-09
>
>If you've reviewed it before, please take a look at the changes.  If
>you'd like to review it, please do.  I'm the shepherd for this draft,
>so comments can be sent to me, to Sam as author, to 
>[email-masked] , or to the IETF general list as appropriate.
>
>In addition to getting general input, I'd like to get a sense of
>whether we have consensus on a couple things.
>
>a).  The statement including "IETF recommends", from section 1.1 of
>the draft:
>
>    "In publishing this memo, the IETF recommends making available

RFC 2606 mentions that an "Informational" specification is published 
for the general   information of the Internet community, and does not 
represent an Internet community consensus or recommendation.  Section 
1.1 of the I-D is at odds with that.  I suggest either reviewing the 
intended status of the I-D or changing that paragraph.

Is this I-D getting into user interface guidelines?  If so, it's not 
standard-track material.

Regards,
-sm 

From: Simon Josefsson <[email-masked]>
To: Lisa Dusseault <[email-masked]>, Sam Hartman <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Cc: [email-masked], [email-masked]
Subject: [Ietf-http-auth] Re: Request for review and consensus -- draft-hartman-webauth-phishing
Date: Mon, 08 Sep 2008 09:02:42 -0000

The document says that the intended status is 'Informational'.
Statements such as "IETF recommends", and normative words such as 'MUST'
as used as per RFC 2119, appears inconsistent with the intended use of
the 'Informational' status (RFC 2026 4.2.2):

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.

Thus, I suggest that either

1) The intended status of the document is changed to
   Best-Current-Practice.

2) The normative words, references to RFC 2119, and statements regarding
   'IETF recommends' are removed.

I would prefer 1).

Thanks,
Simon

Lisa Dusseault <[email-masked]> writes:

> You may have seen this draft a year ago; Sam is back working on it and
> produced version -09 last month.
>
> http://tools.ietf.org/html/draft-hartman-webauth-phishing-09
>
> If you've reviewed it before, please take a look at the changes.  If
> you'd like to review it, please do.  I'm the shepherd for this draft,
> so comments can be sent to me, to Sam as author, to
> [email-masked] , or to the IETF general list as
> appropriate.
>
> In addition to getting general input, I'd like to get a sense of
> whether we have consensus on a couple things.
>
> a).  The statement including "IETF recommends", from section 1.1 of
> the draft:
>
>    "In publishing this memo, the IETF recommends making available
>    authentication mechanisms that meet the requirements outlined in
>    Section 4 in HTTP user agents including web browsers.  It is hoped
>    that these mechanisms will prove a useful step in fighting phishing.
>    However this memo does not restrict work either in the IETF or any
>    other organization.  In particular, new authentication efforts are
>    not bound to meet the requirements posed in this memo unless the
>    charter for those efforts chooses to make these binding
> requirements.
>    Less formally, the IETF presents this memo as an option to pursue
>    while acknowledging that there may be other promising paths both now
>    and in the future."
>
> b) Whether the document should require mutual authentication (section
> 4.4).
>
> Thanks,
> Lisa D.

From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Thu, 04 Sep 2008 12:33:10 -0400
Subject: [Ietf-http-auth] [Peter Gutmann] Re: [saag] Request for review and consensus -- draft-hartman-webauth-phishing

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked]
Date: Fri, 05 Sep 2008 03:26:10 +1200
Cc: [email-masked]
Subject: Re: [saag] Request for review and consensus --
	draft-hartman-webauth-phishing
Sender: [email-masked]
	Errors-To*saag, 0.00062, Sender*saag+bounces, 0.00062,
	List-Help*saag, 0.00062, List-Post*<mailto+saag, 0.00062,
	mutual+authentication, 0.00070,
	In-Reply-To*osafoundation.org>, 0.00082,
	To*secdir+mit.edu, 0.00090, osafoundation+org>, 0.00099,
	To*ietf.org+secdir, 0.00099, <lisa+osafoundation, 0.00099,
	<lisa, 0.00099, Dusseault+<lisa, 0.00099,
	Subject*Request+for, 0.00111
MIME-Version: 1.0

Lisa Dusseault <[email-masked]> writes:

>You may have seen this draft a year ago; Sam is back working on it and
>produced version -09 last month.
>
>http://tools.ietf.org/html/draft-hartman-webauth-phishing-09
>
>[...]
>
>b) Whether the document should require mutual authentication (section 4.4).

Yes, absolutely!  The whole reason why phishing works is that the site is
never authenticated, without mutual auth (and specifically strong mutual auth,
e.g. some form of cryptographic challenge-response mechanism rather than the
pretend-auth of "do you recognise this image?" that some US banks have
adopted) you've not really achieving much.

Peter.
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: pgut001 <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-http-auth] Re: [saag] Request for review and consensus -- draft-hartman-webauth-phishing
Date: Thu, 04 Sep 2008 15:26:35 -0000

Lisa Dusseault <[email-masked]> writes:

>You may have seen this draft a year ago; Sam is back working on it and
>produced version -09 last month.
>
>http://tools.ietf.org/html/draft-hartman-webauth-phishing-09
>
>[...]
>
>b) Whether the document should require mutual authentication (section 4.4).

Yes, absolutely!  The whole reason why phishing works is that the site is
never authenticated, without mutual auth (and specifically strong mutual auth,
e.g. some form of cryptographic challenge-response mechanism rather than the
pretend-auth of "do you recognise this image?" that some US banks have
adopted) you've not really achieving much.

Peter.

From: Lisa Dusseault <[email-masked]>
To: HTTP Working Group <[email-masked]>, [email-masked], [email-masked], Apps Discuss <[email-masked]>
Date: Wed, 3 Sep 2008 13:41:39 -0700
Cc: [email-masked]
Subject: [Ietf-http-auth] Request for review and consensus -- draft-hartman-webauth-phishing

You may have seen this draft a year ago; Sam is back working on it and  
produced version -09 last month.

http://tools.ietf.org/html/draft-hartman-webauth-phishing-09

If you've reviewed it before, please take a look at the changes.  If  
you'd like to review it, please do.  I'm the shepherd for this draft,  
so comments can be sent to me, to Sam as author, to [email-masked] 
, or to the IETF general list as appropriate.

In addition to getting general input, I'd like to get a sense of  
whether we have consensus on a couple things.

a).  The statement including "IETF recommends", from section 1.1 of  
the draft:

    "In publishing this memo, the IETF recommends making available
    authentication mechanisms that meet the requirements outlined in
    Section 4 in HTTP user agents including web browsers.  It is hoped
    that these mechanisms will prove a useful step in fighting phishing.
    However this memo does not restrict work either in the IETF or any
    other organization.  In particular, new authentication efforts are
    not bound to meet the requirements posed in this memo unless the
    charter for those efforts chooses to make these binding  
requirements.
    Less formally, the IETF presents this memo as an option to pursue
    while acknowledging that there may be other promising paths both now
    and in the future."

b) Whether the document should require mutual authentication (section  
4.4).

Thanks,
Lisa D.