Key renewal when the sequence counter is only 32-bit If we look at the use-case that our sequence counter within our TLS communication is only 32-bit, would an automatic key re-newal be necessary a lot more frequently? We're going to use state-of-the-art algorithms consisting of AES-GCM (at least 128-bit keys) and HMAC-256. I'm referring to the answer posted here - https://security.stackexchange.com/questions/55454/how-long-does-an-https-symmetric-key-last - where it states that key renewal would not be necessary due to the substantial amount of data that can be encrypted with AES without the necessary need for a key renewal.
The sequence counter is not the one used within TLS but a protocol specific one. We're not sure if we continue with the &quot;normal&quot; TLS handling after the handshake has been done. We're going to use EAP-TLS for the handshaking. So we don't know if we make use of the implicit 64-bit sequence counter of TLS - would this make a difference for the question asked above?
The standard rule is simple: Re-key whenever the sequence counter would (likely enough) repeat. For incrementing sequence counters this should be the case when they overflow.
If you're using AES-GCM and you were to pick the (96-bit) nonces randomly, re-keying after $2^{32}$ messages would be recommended. However given that you appear to use an actual counter and feed it into GCM's nonce input re-keying on wrap-around is good enough - which incidentally for 32-bit counters would also happen around $2^{32}$ messages.
If you used a 64-bit counter, the previous thought would extend somewhat and a re-key would be required at last every $2^{64}$ messages. However for reasons of the security proof you should really re-key after hitting $\sigma+q=2^{48}$ with $q$ being the number of nonces encrypted and $\sigma$ being 1/16th of the total number of bytes encrypted while not encrypting more than 64GiB per nonce-key pair.