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
