Key life time tracking

[gloinul]

So the different cipher algorithms have different life time in how many invocations or total amount of encryption blocks that can be safely processed. For example AES GCM TLS states in RFC 8446:

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of approximately 2^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached.

When using multipath this limit is across all paths as they use the same key, only ensure unique NONCE input to avoid any two-time pads. Thus, I think the document needs to note that the implementation will have to track their key-usage based on the cipher across all the paths.

[mirjak]

@gloinul Why do you think we need to state anything in addition to what the base QUIC spec is doing?

[gloinul]

Because your key-limit tracking implementation may not have been implemented to support the usage of multiple Nonces and could therefore easily fail. Therefore an informational statement in the security consideration would be good to help ensure that implementors verify that their implementation count invocations independent of nonce for a key.

[kazuho]

@gloinul Makes sense. I think our advice should be based on the numbers written in RFC 9001 B.1.1. but otherwise I concur.

[gloinul]

Sure, pointing to that the limits in RFC 9001 B.1.1 applies to all the paths is likely all that is needed. And it is not really a conflict, just clarification that with "connection" we mean the sum of all transmitted on all paths.