Re: [tcpm] TCP-AO: Text for New_Key Process

At Mon,  2 Feb 2009 09:43:32 -0800,
touch@ISI.EDU wrote:
> 
> Quoting Eric Rescorla <ekr@networkresonance.com>:
> 
> > At Sun, 01 Feb 2009 13:49:14 -0800,
> > Joe Touch wrote:
> > > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > FYI - there's an important reason not to use a separate flag bit. Doing
> > > so requires parsing the bits of the incoming packet, i.e., this adds
> > > extra processing. It also indicates to everyone on the wire that a key
> > > change is pending; when using only the KeyID, no extra parsing is needed
> > > and the meaning of a changing key is opaque to those on the wire.
> > 
> > The extra parsing hardly strikes me as a severe burden and I don't
> > really understand why we would care if an observer knows that a key
> > change is imminent.
> > 
> > 
> > > Using a key flag means that one side can only ever tell the other end
> > > "ready to use the new key", not which key (if there could be more than
> > > one). That means that if you try it once and it fails and you want to
> > > try it again, you might have to wait MSL (a few minutes) to try it
> > > again, otherwise an old packet might indicate 'ready to receive the new
> > > key" for the wrong key.
> > 
> > Well, I don't really favor they ke flag approach, but it occurs to
> > me that this is easily fixed by replacing the key flag with a 
> > "ready to use" byte. Recall that the length of the MAC is tied
> > to the key so if you know the key-id you know the length of the
> > MAC. This makes the Length byte partly redundant. Accordingly,
> > you could have the following format:
> > 
> >  - Kind (1)
> >  - Length (1)
> >  - Key-ID (1)
> >  - Ready-keys [variable]
> >  - MAC
> 
> That is variable length, even when the active key has not changed; that means
> conditional parsing is required, which is cumbersome.

s/cumbersome/trivial/

> We wanted to avoid
> conditional parsing even to save a single byte (the odd/even mechanism I
> suggested in earlier drafts). This seems even more awkward and unnecessary.

I'm not sure what you mean "we". I wanted to avoid the odd/even mechanism
because I thought it was kludgy, but necause I wanted to avoid conditional 
parsing.

> > > Overall, using just the keyID value as the indicator seems much more
> > > flexible to and simple to me.
> > 
> > It's marginally simpler for the implementor of AO and a huge pain for
> > everyone else.
> 
> It is simpler for the AO specification, simpler for the implementer, and exactly
> the same effort for everyone else (i.e., the user/process changing over the
> keys). 

Well, obviously people can differ about what's simpler, but
I don't agree with this. 

Either the user has to create bogus keys used solely as a key change
signal or there has to be logic pulled up into some putative (i.e.,
nonexistent) application layer key management logic to do the signally
you suggest. I don't consider that simpler.

-Ekr

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm