Before I get started, let me say that this should be taken with a very large grain of salt. I am not a technical expert in these areas. I've only done a fair amount of reading and following along with standards efforts. Conclusions here should be questioned thoroughly and corrected as necessary, but since no one else seems to be willing to systematically look into the performance argument for signatures vs. SSL/TLS, I thought I'd just sit down for a couple of hours and pound it out. The following is the result of that work.
** Resource access without SSL/TLS - Signatures vs. Bearer-tokens ** The crux of the trade-off comes down to this: In the case of signed authorization information (with a nonce), a Man in the Middle (MITM) attacker owns the individual message. The MITM can do the following: 1. Decline to deliver the message 2. Hold the message and deliver it later (subject to constraints on timestamp validity - so this is a limited attack) 3. Deliver the message with altered contents (only if the contents themselves are not signed) In the case of bearer-token authorization, a MITM owns the entire connection. The MITM can do the following: 1. Decline to deliver the message 2. Hold the message and deliver it later 3. Change the timestamp (if one is used at all) 4. Change the contents of the message 5. Create an arbitrary number of new messages with arbitrary contents using the bearer-token and deliver those (subject to bearer-token invalidation) In my opinion, #5 makes bearer-tokens without SSL/TLS unusable in nearly all use cases. Any use case where spam is a threat, for example, is not an acceptable use case because of this attack because any MITM can send an arbitrary number of spam messages that the provider application will show as coming directly from the user. If you think Twitter direct-message spam is bad now... Because of this and other possible attacks (successfully impersonating a provider gets you the bearer-token, for example), I think that bearer-tokens without SSL/TLS are not worth considering further for the vast majority of use cases. ** So what about SSL/TLS? Can't we just use that for everything and forget about signatures? ** Yes, but there are tradeoffs. The most important and unavoidable tradeoff is performance. The performance tradeoff comes in two flavors: 1. Connection latency to bootstrap the connection (from the asymmetric/public-key encryption operations) 2. Processing to encrypt requests (from the symmetric/private-key encryption operations) Connection latency is incurred to the public-key cryptography operations that are used to facilitate the exchange of a shared secret, which can then be used in the much more efficient private/symmetric key cryptography used to encrypt the individual messages. Research (1) indicates that, on the web server, SSL introduces approximately a 70% overhead over basic HTTP for small requests and that of this overhead almost 90% is incurred in the public key operations. As request size increases, the public key operation overhead remains constant while the private key operations to encrypt the request scales linearly with request size. As a result, the actual act of encrypting the request becomes the limiting factor relatively quickly for large requests. Keep in mind, this is additional latency on the web server, not on the client. Other research (2) indicates that clients may be even more resource-bound for these types of operations, resulting in even more severe latency problems. It's important to note that these two types of performance impact become problematic under different use cases. ** When SSL makes sense and when it doesn't ** SSL has negative performance impacts which will result in real user experience impacts in certain situations. Service providers can use specialized hardware to significantly accelerate the necessary cryptography operations, but any client smaller than a medium-sized web application provider will not be able to afford the cost of such infrastructure. As such, these clients will suffer a user experience impact from the required use of SSL/TLS connections in some situations. What are these situations? Connection latency is an issue when new connections must be established for most operations. This is the case for intermittent API requests. Some use cases where this could be an issue (keeping in mind that even an extra fraction of a second of wait-time is a user-experience penalty that many applications may be unhappy paying): 1. Display statistics in a rich/desktop app in response to a user request (Ego app on iPhone requesting statistics from Google Analytics, for instance) 2. Check for new messages in a rich/desktop in response to a user request (Dashboard widget, for example) 3. Request data within a web application from a little-used third-party provider in response to a user request (web app like youcalc.com with ability to connect to arbitrary OAuth-enabled datastores) Meanwhile, encryption of the request becomes an issue for large request uploads and download especially. Some examples: 1. Video and media file access requests, including streaming 2. Google Docs document list API upload/download requests In both of the situations outlined above, SSL/TLS imposes a performance overhead that should theoretically have user experience implications. As I've been thinking about this issue, the following matrix has proven helpful in visualizing the problem space and helping to show that SSL/TLS is a clear winner in only a limited (but admittedly very common) portion of the problem space. --------------------------------------------------------------------------------------------- | | Sensitive to connection latency | Not sensitive to connection latency | --------------------------------------------------------------------------------------------- | Large requests | SSL/TLS not a good option | SSL/TLS may be an option | --------------------------------------------------------------------------------------------- | No large requests | SSL/TLS may be an option | SSL/TLS is a good option | --------------------------------------------------------------------------------------------- ** How does signing address these use cases? ** The answer to this question depends on the form that signing ends up taking. If only the authentication parameters are signed, then we are in a situation similar to OAuth 1.0a in which latency is minimal because the hash operation used in the signing is cheap and is executed on a very small amount of data. Further, performance is unrelated to request size because only the authentication parameters are signed and the length of these parameters are unrelated to the request payload. If full message signing is required, then we start to run into the encryption penalty, as effort to calculate the hash of the entire payload should scale more or less linearly with the size of the payload. However, connection latency should remain minimal for small requests. Of course, using signatures without transport-layer security brings with it a whole new matrix of known security considerations. As mentioned at the beginning of this little essay, from a security perspective, signing appears to be at least as good in all respects as bearer tokens sent in the clear. ** Conclusion ** There are theoretical and currently deployed use-cases in which dispensing with SSL/TLS and signing at least the authentication parameters of a request makes sense. These are use cases in which SSL/TLS has an undesirable user experience impact and in which leaving the request payload in the clear does not have significant negative security impacts. For this reason, and because the signing approach is the predominant deployed OAuth method (even though SSL/TLS with a bearer token is an option), we should maintain a signature method in the current draft. ** References ** 1. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.62.8589&rep=rep1&type=pdf - Anatomy and Performance of SSL Processing - Li Zhao, Ravi Iyer, Srihari Makineni, Laxmi Bhuyan - p. 4 is the meat 2. http://iweb.tntech.edu/hexb/publications/https-STAR-03122003.pdf - A Performance Analysis of Secure HTTP Protocol - Xubin He On Thu, Mar 4, 2010 at 2:00 PM, Blaine Cook <[email protected]> wrote: > One of the things that's been a primary focus of both today's WG call > and last week's call is what are the specific use cases for > signatures? > > - Why are signatures needed? > - What do signatures need to protect? > > Let's try to outline the use cases! Please reply here, so that we have > a good idea of what they are as we move towards the Anaheim WG. > > b. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
