On Tue, Jan 12, 2010 at 12:43 PM, Derrick Brashear <[email protected]> wrote: > On Tue, Jan 12, 2010 at 11:56 AM, Tom Keiser <[email protected]> wrote: > > Generally, it looks good. > As before, I'm uncertain it's reasonable to cite the kolya Rx spec as > normative given how it's referred to. >
Hi Derrick, First, thank you for the feedback. I've published a new draft with your suggested reference change. Note: I inadvertently uncommented the boilerplate appendix section in the process; I will fix in -02. http://tools.ietf.org/html/draft-tkeiser-rxrpc-sec-clear-01 http://openafs.sinenomine.net/~tkeiser/draft-tkeiser-rxrpc-sec-clear-01.html http://openafs.sinenomine.net/~tkeiser/draft-tkeiser-rxrpc-sec-clear-01.xml /afs/sinenomine.net/user/tkeiser/public_html/draft-tkeiser-rxrpc-sec-clear-01.txt /afs/sinenomine.net/user/tkeiser/public_html/draft-tkeiser-rxrpc-sec-clear-01.html /afs/sinenomine.net/user/tkeiser/public_html/draft-tkeiser-rxrpc-sec-clear-01.xml > The attacks possible on multihome give me pause but given the security > you get with clear, it's almost certain not worth worrying about. > Admittedly, they give me pause as well. My goal was to provide a means to work around renumbering on existing connections that: a) minimizes round trips, and b) requires no changes to existing Rx applications. I need to re-read my language to be sure, but I don't think any of this precludes API-level tunables that allow clients or servers to explicitly deny seamless renumbering in favor of call error codes -- which, combined with the new security object, allow the caller to introspect into the purported renumbering event and make informed decisions about how to recover from the fault in a timely manner. -Tom _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
