Draft: draft-ietf-tls-tls13

Commentary: Is good . 
 The counter has a size of ( 2 ^ 64 - 1).The records are  ( 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 910 TB 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  , 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 : ( let 's say 2.5 - 3 days with overhead ) . 
 Why do you divide by ( 2 ^ 14 + 2048 ) ? Should n't it be a multiplication with the minimum record size ? 
 I do n'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 . 
 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 ca n'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 . 
 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  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   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 . noted that you do n'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 .
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
The traffic keys are computed from xSS, xES, and the master_secret as
described in traffic-key-calculation below.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.