(this is not aimed at John Kemp) I understand that some providers will not want to bother with the extra security for their own reasons. I am willing to assume they are doing this fully aware of the repercussions of their actions. What I don't understand is why should the protocol - which is aimed at interoperability - bother with it?
We got people here representing many companies, large and small. Can one of them please raise their hand and ask for this feature? And if they do, can they explain how they justify providing poor security to their users? I am no longer interested in the argument that somewhere there are valid use cases. Writing a protocol for scenarios that are not anchored in reality is bad. OAuth 1.0 does not require using a secure channel for sending token secrets because people claimed it will be a problem for some providers. So far, no such providers showed up. If someone want to argue the need of no-crypto / no-HTTPS, while showing how that need justifies subjecting the web to more bad protocols and poor foresight, I am eager to listen. If you don't care about security, you are free to implement the protocol poorly. There is no OAuth Police to enforce servers to check signature and reject requests with bad ones. At least by forcing such cases to break the protocol, we are forcing them to make an active decision and we get their API users to notice. There is also a case to be made about pushing the envelope when it comes to security. The more services use TLS, the cheaper and easier it will get. That's economics 101. And unlike writing new code for new OAuth signatures, requiring TLS will simply mean linking another library and making a function call. My vote is to start with an HTTPS requirement for any unsigned request, and let those who have real reasons to object show up. None of the current users of OAuth 1.0 will be able to claim this since they all use HTTPS for all such requests. EHL On 1/14/10 5:59 AM, "John Kemp" <[email protected]> wrote: > 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 "[email protected]" 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-appli >> cations.html >> >> 2010/1/14 John Kemp <[email protected]>: >>> >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
