+1. Obtaining a certificate is far from an onerous requirement... On 1/14/10 9:41 PM, Eran Hammer-Lahav wrote: > (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 >>>>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
