Asynchronous re-keying support

[xisentian]

As discussed during IETF 123

[ekr]

I'm not sure how much this is really a requirement. Unless you're rekeying nearly constantly--which a lot of systems avoid with PQ--does it really matter if you need to absorb a round trip or two before the keys become effective?

[br-hale]

In space, especially as networking moves deeper into space (which is the scope of TIPTOP), round trips become a problem. If a device cannot unidirectionally update keys and is dependent on interactions with other device(s) before that can be accomplished, then there is risk of 1) large windows of compromise, 2) interdependencies that have to be met before keys can be updated (which do not in practice exist in LEO or terrestrial applications), and 3) increased attack potential from both of those.
Under (2) a device would have to pre-plan (potentially days in advance) to update keys. In normal terrestrial communication, waiting for action from another other party before a key update is complete is fairly minor (very low wait time means that it is not a big consideration). When you have to wait hours and days on the action of another entity to update security, it starts to matter.
This is seen even more under the risks of (3). If packet loss occurs (which is also to be expected), then a handshake response flow may be lost, which then means that the initiator is waiting on a timeout and the reciever actually cannot (or should not) use the new key until there is actually confirmation of receipt (explicit confirmation becomes important when there are long delays and one needs assurance that data can actually be decrypted if received). Depending on the timeout window setting, plus delays of many hours to even days on the round trip itself, it may be a substantial amount of time before parties would even know to restart a key update attempt. This makes attacks against key rolling quite trivial and - in the event of compromise - enables attacks to easily force continued use of the existent key.

Consequently, it is essential to absolutely minimize the RTT for key updates and co-dependency between send/receiver within them. Optimizations for terrestrial networks are different than in space.

[wesley-eddy]

I'm not an expert, but it does sound like a "nice to have" capability.

Past missions have typically used lower layer crypto, as most "applications" access the data link layer directly. The key management practices vary, but planning/scheduling is tied in, and being bulk at the link layer there aren't tons of keys to manage (like you might have with more specific security associations at higher layers).

So, I could definitely at least see this as a nice to have feature, that could become a stronger requirement if we're successful in building larger networks further from Earth.

[xisentian]

being bulk at the link layer there aren't tons of keys to manage (like you might have with more specific security associations at higher layers)

I don't agree that we ought to assume everyone implements link-layer encryption - especially in new architectures that are more dynamic and have multitenancy or peering requirements but also need separated domains of security. Asynchronous re-keying would support such flexible architectures.

Key updates don't need to be frequent and we can plan for them but, to echo @br-hale, it is essential to reduce transmission overhead for key updates and co-dependency on sender/receiver statuses. These are nice features to have if the network is to scale.