Re: [OAUTH-WG] problem statement

Peter Saint-Andre <stpeter@stpeter.im> Wed, 07 September 2011 00:21 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E1421F8D2F for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 17:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWGz8c1oOhNn for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 17:21:17 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEC821F8ABE for <oauth@ietf.org>; Tue, 6 Sep 2011 17:21:14 -0700 (PDT)
Received: from squire.local (unknown [216.17.251.17]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 77746418BB; Tue, 6 Sep 2011 18:25:56 -0600 (MDT)
Message-ID: <4E66B964.2060808@stpeter.im>
Date: Tue, 06 Sep 2011 18:23:00 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: Melinda Shore <melinda.shore@gmail.com>
References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <CD0B1909-8298-4CC3-B273-7B26E71EAB31@hueniverse.com> <4E666512.7010701@mtcc.com> <F4839FCD-CA73-4450-AD12-E07D46BB7746@hueniverse.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <CAMrm-MJHKTxaj1iEm_Lr=X92sOiWZcYN4F6dNqb5w5gh4OPndQ@mail.gmail.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <E3DEC4C8-6BB0-44EE-821A-7589F5DC6462@jkemp.net> <4E669D3C.5000900@gmail.com>
In-Reply-To: <4E669D3C.5000900@gmail.com>
X-Enigmail-Version: 1.3.1
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] problem statement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2011 00:21:18 -0000

On 9/6/11 4:22 PM, Melinda Shore wrote:
> On 09/06/2011 12:59 PM, John Kemp wrote:
>> The point is that you have a point.
> 
> He does, and that's in some large part why I don't
> fully understand the temperature of the responses.
> I do not think it's a particularly big deal to stick
> a couple of sentences in the security considerations
> underscoring the fact that OAUTH can't do anything
> about a compromised host or a malicious application.
> I've learned to live with the fact that sometimes
> people implementing or deploying security technologies
> don't fully understand them and it's my impression that
> there's some number of people out there who think that
> OAUTH and other third-party protocols provide sufficient
> protection against password snagging.

I just looked at the most recent specifications for TLS (RFC 5246) and
secure shell (RFC 4253), which I think we'd all agree are two quite
successful security technologies. Neither of those specs says anything
about not protecting humans users from malicious clients that perform
keylogging to capture security-critical data the user might enter. Not
only is OAuth "not a superhero" as John Kemp said, but I fail to see why
we need to document exactly which superhero powers OAuth lacks (given
that it's not reasonable to expect *any* security protocol to have those
powers). IMHO this is gilding the documentation lily.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/