cloudflare
Connections stop working with AES-ciphers because of missing Key Update
If I am not missing something, it seems quiche does not implement "Key Update".
https://datatracker.ietf.org/doc/html/rfc9001#section-6
If a peer initiates a key update setting the Key Phase bit, I am not able to see any logic handling this.
https://github.com/cloudflare/quiche/blob/master/quiche/src/packet.rs#L274
The Key Phase bit in the header is never actually used.
Please note that for AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit is 2^23 encrypted packets (https://datatracker.ietf.org/doc/html/rfc9001#section-6.6), so, in that case, after about 8388608 packets an endpoint might not be able to trasmit anymore.
Am I missing something?
What's the point in having quiche if it's never going to support rfc 9000? Should we all be switching to quic-go?
I would like to bump the priority of this. The situation right now with quiche is unsatisfactory:
- quiche remains silent about ignoring a
KEY UPDATE. The quiche application is unable to detect the situation. - quiche then subsequently drops incoming packets with encryption errors. This is visible in debug logging and not anywhere else. The connection simply stalls.
- in
libcurlwe have transparent connection reuse for transfers. This means there is no easy way for a curl application to avoid running into this limitation.
And this is "just" the client side. Am I to understand that Cloudflare itself nevers sends key updates? When a client does a long session with CF servers, will the key and security of the connection not suffer?
