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

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

With ready-keys being a variable length field listing any keys which
are ready to use but haven't been used yet. This causes a slight
increase in the option size, but only during the transition period.

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

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