Hi Ben, If you just wanted RPC security sooner, you could have deployed rxk5 in 2007. The point of waiting for rxgk was to get compelling features like a secure callback channel.
It is my impression that the YFS implementation implements callback channel security today. I'm not sure quite when the community should make time to get an -interoperable- secure callback channel, but, isn't it, arguably, now? Regards, Matt ----- "Benjamin Kaduk" <[email protected]> wrote: > On Fri, 1 Mar 2013, Russ Allbery wrote: > > > Benjamin Kaduk <[email protected]> writes: > >> On Fri, 1 Mar 2013, Jeffrey Altman wrote: > > > >>> Extended callbacks cannot be fully implemented until there are > >>> protected callback channels. That does not mean there are not > benefits > >>> to protecting the callback channels in a world without extended > >>> callbacks. > > > >> I believe the question at hand is whether those benefits are > sufficient > >> to delay standardizing rxgk. Do you have an opinion on this > question? > > > > Personally, I think an rxgk standard that didn't protect the > callback > > channel would be absurd. > > While I am happy to hear an opinion expressed, merely saying that > something would be "absurd" does not really give me a technical > argument > whose merits I can weigh and consider. At best, I can weigh the > position > against your personal reputation, which is admittedly quite strong. > > 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. > > 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 just don't see that rxgk itself has an inherent dependency on > secure > callbacks; in my mind, secure callbacks are a thing that use rxgk. > > -Ben > _______________________________________________ > AFS3-standardization mailing list > [email protected] > http://lists.openafs.org/mailman/listinfo/afs3-standardization -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
