[AFS3-std] rxgk-afs: moving SetCallBackKey to a separate document?

[Benjamin Kaduk]

On Fri, 1 Mar 2013, Russ Allbery wrote:

> Benjamin Kaduk <kaduk@MIT.EDU> 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