On Mar 1, 2013 6:47 PM, "Benjamin Kaduk" <[email protected]> wrote: > > Thanks for these comments, they are very helpful. > (more inline) > > > On Fri, 1 Mar 2013, Russ Allbery wrote: > >> Benjamin Kaduk <[email protected]> writes: >> >>> Jeff has described the current situation with regard to callbacks and >>> information leakage and denial of service possibility. Given that even >>> with rxgk and a secure callback channel, we still have the problem of rx >>> aborts being unauthenticated, I'm looking at a difference between rxgk >>> now and rxgk later with secure callbacks. Rxgk now gives me secure data >>> transfer and authentication, but leaves me vulnerable to denial of >>> service both at a per-RPC level and a refetching data level, as well as >>> the information leakage about fids and such in use. Rxgk later also >>> gives me secure data transfer and authentication, and leaves me >>> vulnerable to per-RPC denial of service attacks, but closes the data >>> leakage channel and closes the denial of service attack that makes me >>> refetch lots of data. >> >> >>> To me, in the environment I work in, network is cheap, and I don't >>> really care about this class of information leakage; I'd rather have the >>> stronger crypto for authentication and data transfer sooner. I'm >>> interested in hearing why and how the tradeoff leans otherwise in >>> different environments. >> >> >> Whenever I hear anyone talk about a security framework when using the >> phrase "I don't care about this class of information leakage," I feel like >> they're waving a giant red flag. The whole point of rxgk is to modernize >> and fix the AFS security model, and callbacks are a key component of the >> AFS protocol. Leaving them unprotected feels to me like a substantial gap >> in work that has been in scope for rxgk for as long as I've heard it >> discussed. > > > I was trying to say that in the environment I currently work in, these concerns are subsidiary to other concerns. I realize that other environments will have different risk profiles, and was not trying to say that we should discount the leakage entirely. > > That said, modernizing and fixing the AFS security model is a huge task, and we're unlikely to get it perfect the first time around. >
I tend to agree with Russ. Although we could potentially get to market sooner with an afsint-only solution, this does not feel like an advisable tradeoff. While I'm sympathetic to your argument that we are unlikely to get this right the first time, I do think a document entitled rxgk-afs should specify the binding semantics for at least afscbint and afsint. >From my perspective, cache invalidation DoS attacks are potentially quite dangerous: their amplification factor is conceivably enormous, and the potential for causing outages is well understood. I would like to see the callback channel protected in the initial draft, if at all feasible. > >> I'm also quite uncomfortable with the idea of just omitting a part of the >> protocol from the security design. That is exactly the sort of design >> decision that tends to result in unexpected negative security implications >> later. Giving attackers unprotected channels into the protocol should >> always be scary. Attackers are often quite a bit more creative than >> protocol designers. I realize this is a problem with rx aborts >> regardless, but callbacks carry more substantial data. > > > So you are arguing that we should consider AFS callbacks as a first-class part of its use of the rx protocol when we are upgrading the security class, even though they currently only use the null security class? I don't have an obvious counter to that; it is good food for thought. > > >> I don't have a concrete attack that I can point at beyond what Jeff >> already mentioned, but dropping this work is something that I think has a >> bad architectural smell. > > > Sure, this is a good sort of input to get from experienced implementors. > > >>> I'm happy to make securing the callback channel be the next thing done >>> after rxgk; I think it would give us secure callbacks at about the same >>> time as blocking rxgk on secure callbacks, but we would get rxgk >>> sooner. >> >> >> I don't think this sort of timing in the protocol work is going to have >> much, if any, real-world effect on the timing of availability of >> deployable software. The callback security work has to happen anyway and >> you even agree that it's next; what specifically is being gained from >> publishing rxgk without it? > > > My understanding is that none of the code I currently have can go into the openafs tree until there is a final standard. I think it would be healthiest to get ongoing review and integration of rxgk code, having the core framework pieces in the tree even before all of the integration work is finished. (Maintaining a huge branch out of tree is a substantial effort just on its own!) Integration of the core code would also make it easier for integration work to proceed in parallel for the various services; I believe that there are other people who have volunteered to help with development once it becomes reasonable to do so. Such collaboration could certainly be done out-of-tree, but that seems suboptimal to me. Of course, I could be wrong that integrating the core would make parallel development easier. As it is, I am reluctant to even bring up broad architectural questions on openafs-devel without a spec in hand. > Yes, it is unfortunate that longer development times lead to greater code integration headaches. However, giving this argument significant weight is difficult--because acceding to it can negatively impact our judicious deliberation. Cheers, -Tom
