/* * key_id increments to KEY_ID_MASK then recycles back to 1. * This way you know that if key_id is 0, it is the first key. */ ++session->key_id; session->key_id &= P_KEY_ID_MASK; if (!session->key_id) { session->key_id = 1; }Okay, so it does roughly what I assumed it does. But strictly speaking this is not a renegotiation key then. Once the first renegotiation happens the key will be used for ALL control channel packets, is that correct? So how does that avoid the replay attack? I mean it obviously avoids it for the first renegotiation, but could you replay the first renegotiation afterwards? Or does that not work due to increasing key_id/packet_id?
We do initialise the replay protection on the tls-crypt keys. So an attacker can only replay packets that are already known to both peer and they will drop them. While you can get the same level of protection with tls-crypt (without dynamic key) using --replay-persist option, I don't think I have seen this option ever being used.
Arne _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
