Change:
Is good.
The counter has a size of (2^64-1).The records are max (2^14 + 2048). So, my bold calculation would come to (2^64-1) / (2^14 + 2048) / 2^40 = 910.22 TiB of data. In Big Data, video streaming and other mass data cases 910TB data can be a limitation. I would like to propose the counter to go to 2^128-1, which would result in a connection that can reach (2^128-1) / (2^14 + 2048) / 2^80 = 1.52 * 10^10 YiB. If byte preservation is an issue, I'm willing to accept 2^96-1 as the counter max, resulting in (2^96-1) / (2^14 + 2048) / 2^80 = 3.55 YiB as maximum connection.
On a 40Gibit line this will take less time than one might expect: URL (let's say 2.5-3 days with overhead).
Why do you divide by (2^14 + 2048)? Shouldn't it be a multiplication with the minimum record size?
I don't see much support for this. Please take it to the list if you want to pursue it.
Consensus at interim: No protocol action needed. Add calculations to security considerations.
Also, consensus is that the math above is wrong.
NAME would you be willing to contribute a PR with a paragraph or two of guidance on the limits for AES-GCM and ChaCha20
Yes. What happened to the Key Update message? I can't find it in the text, and that would be a logical place to mention the limitations as well as in the security considerations section.
URL If you want to just send a PR against that branch that would be fine. Or really, whatever form you want and I can manually merge.
If we ditch renegotiation (), then we will need a way to rekey sessions to extend their lifetime. Nico suggests that sending ChangeCipherSpec and then using an increasing counter to extract new keys (i.e., add a counter to the key expansion PRF input), which would seem to be sufficient.
We have asked David McGrew about the theoretical limits on AES-GCM, we can find the same info for ChaCha+Poly1305. When we have that info, we will make an assessment as to how urgent this is. That will determine how soon we define this mechanism. NAME noted that you don't even have to negotiate to enable rekeying: if you send the rekey message and rekey, your connection will either be rekeyed, or killed by the peer.

Discussion:
server_key_exchange_RESERVED(12), certificate_request(13), server_hello_done_RESERVED(14), certificate_verify(15), client_key_exchange_RESERVED(16), server_configuration(17), <del> finished(20), (255) } HandshakeType; </del> <ins> finished(20), key_update(24), (255) } HandshakeType; </ins> The TLS Handshake Protocol messages are presented below in the order they MUST be sent; sending handshake messages in an unexpected order

to receive an arbitrary number of such messages before receiving the Authentication messages. <ins> 6.3.5.3. struct {} KeyUpdate; The KeyUpdate handshake message is used to indicate that the sender is updating its sending cryptographic keys.  This message can be sent by the server after sending its first flight and the client after sending its second flight.  Implementations that receive a KeyUpdate message prior to receiving a Finished message as part of the 1-RTT handshake MUST generate a fatal "unexpected_message" alert.  After sending a KeyUpdate message, the sender SHALL send all its traffic using the next generation of keys, computed as described in updating- traffic-keys.  Upon receiving a KeyUpdate, the receiver MUST update their receiving keys and if they have not already updated their sending state up to or past the then current receiving generation MUST send their own KeyUpdate prior to sending any other messages. This mechanism allows either side to force an update to the entire connection.  Note that implementations may receive an arbitrary number of messages between sending a KeyUpdate and receiving the peer's KeyUpdate because those messages may already be in flight. Note that if implementations independently send their own KeyUpdates and they cross in flight, this only results in an update of one generation; when each side receives the other side's update it just updates its receive keys and notes that the generations match and thus no send update is needed. Note that the side which sends its KeyUpdate first needs to retain the traffic keys (though not the traffic secret) for the previous generation of keys until it receives the KeyUpdate from the other side. </ins> 7. In order to begin connection protection, the TLS Record Protocol

the underlying hash function for HKDF RFC5869.  SS and ES denote the sources from the table above. <del> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below. </del> <ins> The traffic keys are computed from xSS, xES, and the traffic_secret as described in traffic-key-calculation below.  The traffic_secret may be updated throughout the connection as described in updating- traffic-keys. </ins> Note: although the steps above are phrased as individual HKDF-Extract and HKDF-Expand operations, because each HKDF-Expand operation is

7.2. <ins> Once the handshake is complete, it is possible for either side to update its sending traffic keys using the KeyUpdate handshake message key-update.  The next generation of traffic keys is computed by generating traffic_secret_N+1 from traffic_secret_N as described in this section then re-deriving the traffic keys as described in traffic-key-calculation. The next-generation traffic_secret is computed as: traffic_secret_N+1 = HKDF-Expand-Label(traffic_secret_N, "traffic secret", "", L) Once traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete traffic_secret_N.  Once the directional keys are no longer needed, they SHOULD be deleted as well. 7.3. </ins> The traffic keying material is generated from the following input values:

The following table indicates the purpose values for each type of key: <del> 7.2.1. </del> <ins> 7.3.1. </ins> The handshake hash is defined as the hash of all handshake messages sent or received, starting at ClientHello up to the present time,

hash" because it contains all the handshake messages involved in establishing the session, up to and including the client's Finished. <del> 7.2.2. </del> <ins> 7.3.2. </ins> A conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is used as the shared secret, and is used in the key schedule as specified above.  Leading bytes of Z that contain all zero bits are stripped before it is used as the input to HKDF. <del> 7.2.3. </del> <ins> 7.3.3. </ins> For secp256r1, secp384r1 and secp521r1, ECDH calculations (including parameter and key generation as well as the shared secret