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

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. 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.

> > 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). 

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