Hi Blaine, On Jan 14, 2010, at 7:10 AM, Blaine Cook wrote:
> OAuth WRAP is very similar to cookies as deployed by major vendors. How is that relevant to _this_ discussion (I apologize, I don't know much about WRAP)? > > Google has just switched to HTTPS-by-default for all GMail > sessions[1], Yes, HTTPS by default, and they are doing it in order to secure the exchange of email - allowing emails to remain confidential on insecure networks. I think that is a strong use-case for requiring confidentiality. But not all use-cases for OAuth need that much confidentiality, or any confidentiality at all. > and my understanding (per [2]) is that access to > authenticated sessions (i.e., full GMail or Google Docs access versus > just displaying "b...@gmail.com" on the page) is always negotiated with > a secure cookie. Thus, Google has made decisions internally to secure > the equivalent of both the Refresh and the Bearer token, short-lived > assurances aside. > > We're also entering an age where we have enough computing power to > *factor* RSA-1024 in non-infinite-time; handheld devices that are > realistically expected to use these protocols have sufficient > computing power and battery life to encrypt HTTP requests and decrypt > the responses (my phone already does this for all Twitter and email > requests; yours probably does, too). I guess my concern about performance is more at the server-side, where many requests may be processed more or less simultaneously. Back in the old days (1997) we had a special crypto hardware accelerator in our Internet-connected proxies, and our non-Internet connected machines wouldn't use SSL at all, because of the performance impact. I'm sure things are better these days, but crypto operations still add performance overhead that may not in practice be necessary for every use-case. > > As such, I can't see how *not* requiring SSL for unsigned requests > could pass muster at an IETF security review. Well, I don't know what is required to pass IETF security review, and perhaps you're right, but the point is really whether there are cases where a combination of short-lifespan + replay-prevention and possibly other non-transport things could provide enough security to allow people to perform real work with OAuth tokens. And I think there are such cases - rather vaguely I could say that the broad category would be anything for which a large volume of authorized requests is possible, and where the "value" in an individual request is low. That certainly does not include email, which I rather think _is_ deserving of confidentiality over insecure networks (of course, Gmail does allow you to turn off https if you are in a more secure network environment). Regards, - johnk > > [1] http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html > [2] > http://googleonlinesecurity.blogspot.com/2009/06/https-security-for-web-applications.html > > 2010/1/14 John Kemp <j...@jkemp.net>: >> >> On Jan 14, 2010, at 1:05 AM, Eran Hammer-Lahav wrote: >> >> [...] >>> >>> QUESTIONS: Are there any valid (such that will pass IETF security review >>> scrutiny) reasons for allowing unsigned requests to be sent in the clear >>> over an insecure channel? Are there use cases for this (regardless of their >>> security properties)? >> >> I am still wavering on this. >> >> I think that using a bearer token with short lifetime and one-time use >> semantics (for example) is probably sufficient security for many use-cases. >> And using TLS/SSL (or even just signing and verifying a signed request) in >> all cases may provide too much performance overhead for some of those cases. >> >> In other words, I think that it's not only channel security we need to >> consider, but a combination of other measures that would, in some cases, >> obviate the need for TLS. >> >> Regards, >> >> - johnk >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
