Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter)

Dick Hardt <Dick.Hardt@microsoft.com> Mon, 30 November 2009 19:57 UTC

Return-Path: <Dick.Hardt@microsoft.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC89A3A68C9 for <oauth@core3.amsl.com>; Mon, 30 Nov 2009 11:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.465
X-Spam-Level:
X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5opXawqZqZx6 for <oauth@core3.amsl.com>; Mon, 30 Nov 2009 11:57:15 -0800 (PST)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 239493A6890 for <oauth@ietf.org>; Mon, 30 Nov 2009 11:57:15 -0800 (PST)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 Nov 2009 11:57:33 -0800
Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Mon, 30 Nov 2009 11:57:07 -0800
From: Dick Hardt <Dick.Hardt@microsoft.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Thread-Topic: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter)
Thread-Index: AQHKcfMcSQLjO+xFt0m7d8bLMYTtBJFPkMqA
Date: Mon, 30 Nov 2009 19:57:05 +0000
Message-ID: <5A9DD209-E811-4591-A26E-287B337082E9@microsoft.com>
References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <ED97F89464499E4D80A68CDCE1E3D1FF020897A1@PACORPEXCMB03.cable.comcast.com> <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <d63be22d-e27c-4307-8402-2fdd740ec723>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Moore, Jonathan (CIM)" <Jonathan_Moore@Comcast.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 30 Nov 2009 19:57:15 -0000

On 2009-11-30, at 9:25 AM, Eran Hammer-Lahav wrote:

> 3. I will leave it up to the security experts to figure out if a PK option in the *authentication* spec is worth having, compared to TLS/SSL. OAuth did not require TLS because it was designed to be friendly to small sites looking to deploy an API without having to deal with certificates. The performance overhead wasn't really the main issue, it was practicality. For example, I would like to be able to write a Wordpress plugin that exposes an address book API using OAuth, without being required to enable SSL on my blog.

Are there implementations of Wordpress plugins using OAuth? ie., was there a real market need for this, or just a perceived need?

If you don't have SSL on your blog management endpoint, then your blog credentials are being transported in the clear. I don't have SSL on my Wordpress blogs, and I'm ok with the risk given the tradeoffs. It seems like many other people are as well currently. 

While I agree it is desirable to improve security, is there real demand for it? 

In choosing where to put efforts, would it be "better" to drive down the barriers to deploying SSL?

-- Dick