Re: [Ietf-http-auth] Request for review and consensus -- draft-hartman-webauth-phishing

[SM <[e-mail]>]

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