Re: [OAUTH-WG] problem statement

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 07 September 2011 01:03 UTC

Return-Path: <eran@hueniverse.com>
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 2F1D121F8DBA for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 18:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599]
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 pGZ7ItcjEMFu for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 18:03:54 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id BFCA521F8DB7 for <oauth@ietf.org>; Tue, 6 Sep 2011 18:03:54 -0700 (PDT)
Received: (qmail 537 invoked from network); 7 Sep 2011 01:05:42 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 01:05:42 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Sep 2011 18:05:41 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Melinda Shore <melinda.shore@gmail.com>
Date: Tue, 06 Sep 2011 18:05:34 -0700
Thread-Topic: [OAUTH-WG] problem statement
Thread-Index: Acxs+kN/rCnmTHhRQu+pvozfCFH1TA==
Message-ID: <6CA555E2-D08C-4707-AFB1-8763EE23BF0A@hueniverse.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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" <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:03:56 -0000

What do you think such a warning would accomplish? There are no ways to mitigate malware (bad client or otherwise), and using passwords make it even easier. 

End users are not going to read the specification and service providers have absolutely no alternatives.

As for the example, the issue you described with accepting every CA is completely irrelavent because changing the root certificates will be done in secrecy by the installed malware. 

I have not seen any argument showing how such a warming makes any difference in deploying OAuth (or not).

Can you propose text and show how it mau affect implementation?

EHL


On Sep 6, 2011, at 17:50, "Melinda Shore" <melinda.shore@gmail.com> 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.
> 
> Melinda
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth