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

SM <sm@resistor.net> Wed, 10 September 2008 00:22 UTC

Return-Path: <sm@resistor.net>
X-Original-To: ietf-http-auth@osafoundation.org
Delivered-To: ietf-http-auth@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 12B9880D30 for <ietf-http-auth@osafoundation.org>; Tue, 9 Sep 2008 17:22:07 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AABEF14222B for <ietf-http-auth@osafoundation.org>; Tue, 9 Sep 2008 17:22:05 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.893
X-Spam-Level:
X-Spam-Status: No, score=-2.893 tagged_above=-50 required=4 tests=[AWL=-0.294, BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVuRK7K0Tiku for <ietf-http-auth@osafoundation.org>; Tue, 9 Sep 2008 17:21:55 -0700 (PDT)
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7556D14222A for <ietf-http-auth@osafoundation.org>; Tue, 9 Sep 2008 17:21:55 -0700 (PDT)
Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id m8A0LO8F027733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 17:21:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1221006093; x=1221092493; bh=FTfY9Q80NQPQS2CaIGPerbSWwkUJeUKt8KAe TjN0tsw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=lJo75VDbl1ktI5V6kDmvycWOdf agIUsX1RTpCUpMrAjpI0hnkB55YcL1wVSMX4yJ/yB2/Qpyt5twwMlnKgbadKUmFNJTN wqSr9D+kNl0vvjQBjGs/eXnwrAQT1pUjnvK4KfOvL5zdL+yUVeXbzzoP+LDyRDIOA05 dMrXo0mIPdk=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=UqIJzVO7zkjthJU5UgPRCseHOofN8fSwkviYcZQ9S1iTpo3W0NsGtvW7vdBDVLg5i 8Pewf357qJnPkl5ZHi5C26tBog0vzR1/NwJTzsX0qYElQefKl8DH1EjgkF+IPzKEI/4 AfcyUp7wLbY6UeeWLbDaxz2Zrmy1QJQk/pbBOWs=
Message-Id: <6.2.5.6.2.20080909153753.02f54d98@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 09 Sep 2008 17:20:46 -0700
To: Sam Hartman <hartmans-ietf@mit.edu>
From: SM <sm@resistor.net>
Subject: Re: [Ietf-http-auth] Request for review and consensus -- draft-hartman-webauth-phishing
In-Reply-To: <tsl8wu1tqp4.fsf@mit.edu>
References: <47490048-25ED-403E-96B9-0D385F764292@osafoundation.org> <6.2.5.6.2.20080908104107.02d68650@resistor.net> <tsltzcqxzjb.fsf@mit.edu> <6.2.5.6.2.20080908125602.02bb9ab8@resistor.net> <tsl8wu1tqp4.fsf@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: ietf-http-auth@osafoundation.org
X-BeenThere: ietf-http-auth@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-http-auth.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth>, <mailto:ietf-http-auth-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-http-auth>
List-Post: <mailto:ietf-http-auth@osafoundation.org>
List-Help: <mailto:ietf-http-auth-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth>, <mailto:ietf-http-auth-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Sep 2008 00:22:07 -0000

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