I like it. Any security issue in having the same content sent twice
with old and then new key?
jfc
At 00:20 03/10/2006, Fred Baker wrote:
I would suggest that a key in the list actually has two timestamps
(virtual or actual) associated with it - a point in time where the
sender should start using it, and a point in time at which the key
should be deleted from the list (eg neither send nor accept). The
biggest problem I see in the algorithm as stated is that only one key
is ever in use - when the sender starts sending the new key, it stops
using the old key, and if the other guy hasn't been configured with
it yet (as Iljitsch supposes) the connection immediately goes plop.
What one wants to happen is more like the following.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf