(was Re: [AFS3-std] Re: Reviving draft-wilkinson-afs3-rxgk)
On Mon, 29 Oct 2012, Andrew Deason wrote:
On Thu, 25 Oct 2012 09:58:03 -0400 (EDT) Benjamin Kaduk <[email protected]> wrote:Probably the biggest issue which is unaddressed is that of key rollover. We use the 16-bit "checksum" field of the RX header to store the key number, and section 8.2 ("Rekeying") currently specifies that when that value would overflow, the connection must be terminated. Andrew Deason asked (April 2012) whether this is necessary, given that we could roll over the 16-bit field and still be confident about what key is in use. "We can be off by one or two, but we cannot be thousands off." Hmm, Simon replied to that with some estimates of how much data can be safely passed through a single AES key, and seemed to think that rollover would be okay to add. I don't see any other replies to that issue, so maybe it is less large than it first seemed, and we should just add the rollover provision.My impression of this is that there's no downside to allowing it to rollover, so regardless of how likely it is for exhaustion to be an issue... I mean, just allow for rollover and the issue is definitely done.
Rollover with the key number being wrapped at 16 bits would result in reusing old keys, which should be avoided. So long as both client and server keep their own 32-bit key_number for the connection, it should be okay. (When I first read the proposal, I read it as wrapping back to 0, so I wanted to clarify in case others were reading it the same way.)
-Ben _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
