Re: [OAUTH-WG] why are we signing?

John Panzer <jpanzer@google.com> Tue, 10 November 2009 02:47 UTC

Return-Path: <jpanzer@google.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 92AB13A68CE for <oauth@core3.amsl.com>; Mon, 9 Nov 2009 18:47:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 idgU+z70ojHa for <oauth@core3.amsl.com>; Mon, 9 Nov 2009 18:47:23 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 78CFF3A681B for <oauth@ietf.org>; Mon, 9 Nov 2009 18:47:23 -0800 (PST)
Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id nAA2llGg022130 for <oauth@ietf.org>; Tue, 10 Nov 2009 02:47:48 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257821268; bh=q64XIX+I7uLktLvA31DT0+rfeW0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=clCaRVhYK4F7H2ZOi/RbBuWG6Qr7EIaUh6L7qXRsnhxfrrXSNIW2tADNWfgTCOGIY gTyWvgCJogKSg0RE6x/7w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=FhcUqHquh9SkvKzJ4SFiNpFJV5jGLqDKUImDF7KT73S/PAABjPk7uFBxDCyGetyUl usPXZLKWoQg10lfnu7nKQ==
Received: from pxi33 (pxi33.prod.google.com [10.243.27.33]) by wpaz17.hot.corp.google.com with ESMTP id nAA2lXl9001256 for <oauth@ietf.org>; Mon, 9 Nov 2009 18:47:45 -0800
Received: by pxi33 with SMTP id 33so23509pxi.4 for <oauth@ietf.org>; Mon, 09 Nov 2009 18:47:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.6.25 with SMTP id 25mr15425391waf.25.1257821265021; Mon, 09 Nov 2009 18:47:45 -0800 (PST)
In-Reply-To: <19B1A486-C1F9-4EAF-9DAE-FD886D829236@microsoft.com>
References: <daf5b9570911082102u215dcf22gf0aeb2f3578e5ea0@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9570911091627i3e70924bnda232246df3918fd@mail.gmail.com> <cb5f7a380911091634r19f20019rabb3d1c8c9c3246f@mail.gmail.com> <19B1A486-C1F9-4EAF-9DAE-FD886D829236@microsoft.com>
From: John Panzer <jpanzer@google.com>
Date: Mon, 09 Nov 2009 18:47:23 -0800
Message-ID: <cb5f7a380911091847v375ca8ddtdbe2ab718162cf90@mail.gmail.com>
To: Dick Hardt <Dick.Hardt@microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] why are we signing?
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: Tue, 10 Nov 2009 02:47:24 -0000

On Mon, Nov 9, 2009 at 6:09 PM, Dick Hardt <Dick.Hardt@microsoft.com> wrote:
>
> On 2009-11-09, at 4:34 PM, John Panzer wrote:
>
>> Counter-argument:  The login pages are protected with https, so
>> their password is protected.
>
> One might then ask why HTTPS is not used for all the other activity if
> it is sensitive. HTTPS is available. Crypto gets cheaper and cheaper
> with Moore's law.

It would be interesting to see the price differential (for peak
traffic/worst case scenario you need to provision for).

Imagine that the resource is, say, a 10MB image.

>
>
>>  Their session cookies are sent in clear text but are themselves
>> encrypted and are refreshed every (say) 10 minutes to minimize
>> exposure from leakage.
>
> A lot of damage could be done in those ten minutes.

But much less than can be done if passwords can be collected and used
later when the user is asleep, to access arbitrary services (and
probably unrelated services because everyone is using the same
email-based username and low-security password for everything).

>
>> The user's data certainly is sent in clear text form and an attacker
>> can both read it and impersonate the user to send data if they grab
>> the cookies, at least for 10 minutes.  So I got nothin' there.
>>
>> (Would bearer token plus a way to securely rotate the token every N
>> minutes make the OAuth session at least as secure as the above
>> scenario?)
>
> I think so. :-)

Don't we want that anyway?

>
> -- Dick
>
>