Thanks for the comment. I am not an expert either, but: On Sun, Mar 7, 2010 at 9:24 AM, Ethan Jewett <[email protected]> wrote:
> 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... > You can make the token short-lived if this is a concern. (Short lived meaning minutes.) And presumably the user is rate limited in the first place, so there is an upper bound on the damage that can be done. It's possible to come up with scenarios where short lived bearer tokens won't work for #5. I'm struggling to come up with any scenarios that really wouldn't want TLS as well. Note that TLS also takes care of the reverse trip -- the MITM cannot lie to the client about what happened, or feed it false information. None of the signature options under discussion sign responses IIRC. > > 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. > I was excited to look at (1) a bit as I think actual research and numbers would be good. It appears that this paper was also published in "IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), Austin Texas, Mar 2005," so the measurements are about 6 years old at this point. I also noticed that they did not mention HTTP keep-alive connections in conjunction with SSL performance. If you are doing a high volume of server to server requests, this would be an obvious optimization in any case, and would amortize the public key operation overhead over a lot of transactions (IIUC). Below you mention the intermittent request case, where you have surprise requests from any of a large number of clients that hit your server (and so there's a cold-start penalty each time). This is a worst case scenario for SSL connections. I wonder what the overhead of SSL is for modern client hardware in these situations (and I'm thinking that in a thin client world, this is a very good use for silicon on the client.) They also didn't really go into the effects of specialized server hardware for SSL, which may not have been as available in 2004(?). > > 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. > For today's realistic request traffic, I've been told that the public key setup is typically the limiting factor. And in fact even with keep-alives turned on the main thing you'd need capacity for at scale is a cold start of your service under load (worst case scenario). The public key operations would be a major issue then. Note that a possible workaround for these large-request situations is to use an SSL-secure API to retrieve a one-time bearer token for use with a subsequent large request (a video upload, say). Since it's one time it can't be used to replay anything. Since it's a large request the overhead of an initial small request is nearly irrelevant. > > 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) > May be better served by a push mechanism in any case... > 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. > Thanks for writing all of this up. It would be good to get some general quantification of user experience latency impact (if everyone agrees that's the main issue) and compare it against the known interoperability issues with signatures. (There's a user experience impact there too.) > > ** 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 >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
