Re: [OAUTH-WG] problem statement

Peter Saint-Andre <stpeter@stpeter.im> Wed, 07 September 2011 01:06 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 3A4A121F8B3D for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 18:06:44 -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 hQehkpLcd7VB for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 18:06:43 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3E121F8B39 for <oauth@ietf.org>; Tue, 6 Sep 2011 18:06:43 -0700 (PDT)
Received: from squire.local (unknown [216.17.251.17]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3845D418BB; Tue, 6 Sep 2011 19:11:26 -0600 (MDT)
Message-ID: <4E66C407.9090209@stpeter.im>
Date: Tue, 06 Sep 2011 19:08:23 -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> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com>
In-Reply-To: <4E66BFF0.9020008@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 01:06:44 -0000

On 9/6/11 6:50 PM, Melinda Shore wrote:
> On 09/06/2011 04:23 PM, Peter Saint-Andre wrote:
>> 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.
> 
> I think there's an argument to be made that the user interface
> is sufficiently different that those might not be a great model.
> But it's also the case that there have been security problems
> with both that may or may not have been avoided in part by
> putting in warnings not to trust every crappy, random CA
> certificate that wafts by, or not to respond "Sure - thanks!"
> to every ssh host key you're offered.

Put me in the "may not have been avoided" camp. We can't legislate
common sense (which, sadly, is all too uncommon).

Look, I spent months working on RFC 6125, which has a title too long to
quote here but basically spends many dozens of pages defining what it
means to check that you're connecting to the right TLS server. That
advice at least is something positive that clients can operationalize.
Documenting a lack of superhero powers seems like a waste of time to me,
but if someone wants to propose a few sentences of text that's up to them.

Peter

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