alternative solution for the key update problem

[marten-seemann]

Building on top of my proposal to get more explicit about Path IDs (#214), I believe there's an easier solution to the key derivation mechanism.

We could derive a new key per path using a HKDF (putting the path ID into the context or label). Each path would then have its own key. This means that:

1. The path ID wouldn't need to be attached to the nonce.
2. Key updates would then happen separately for every path. This removes the need to do anything special (as compared to RFC 9001) for key updates. Especially it wouldn't be necessary to synchronize key updates across paths (see don’t require sending packets on all paths on key updates #209 for problems associated with that logic).

This requires #214, since CIDs would now tightly bound to a path. The receiver of a packet would first determine the path ID of a packet from the connection ID used.

[huitema]

I think this is independent from #214. It would certainly be possible to derive a key per number space, regardless of how we identify the number space.

We did not do that because it felt more complicated than just sticking 32 bits in the nonce. We would need to keep one set of AEAD context per direction per number space. Managing a "key per number space" also implies independent key rotation for each number space.

I think we agreed to not anymore require that some data of each epoch be sent on every path.

[marten-seemann]

I agree that deriving a separate key per CID would work as well. One might consider this is a bigger change from RFC 9001 than deriving a new a new key per path, since the concept of paths naturally needs to more nuanced when specifying multipath than when merely doing connection migration.

I think we agreed to not anymore require that some data of each epoch be sent on every path.

Where was that? The text is still present in the current editor copy, and I can't find a PR that would change that text.

[mirjak]

I guess @huitema is referring to issue #209. Looks like we have agreement there but this still need a PR.

[huitema]

Deriving one key per path requires significantly more memory per path than just changing the nonce -- you need buffers for the keys, the state, possibly some computations. I am aware of at least one scenario in which that matters a lot: messaging servers that handle a lot of long duration connections, with not much traffic. The server scaling is dominated by memory issues. Yet these long term connections would benefit a lot from the additional reliability of multipath.

[mirjak]

Can we close this issue with the merge of #257?

[mirjak]

Closing as #257 was merged