Draft: draft-ietf-tls-tls13

Commentary: I forsee some merge conflicts in the future , as there 's already and I have plans to rototill this section a bit more than you do here . 
 This wo n't conflict with .  is good at detecting identical changes .
Paragraph (version A):
The AEAD output consists of the ciphertext output by the AEAD
encryption operation.  The length of the plaintext is greater than
TLSPlaintext.length due to the inclusion of TLSPlaintext.type and any
padding supplied by the sender.  The length of the AEAD output will
generally be larger than the plaintext, but by an amount that varies
with the AEAD algorithm.  Since the ciphers might incorporate
padding, the amount of overhead could vary with different lengths of
plaintext.  Symbolically,
Paragraph (version B):
The AEAD output consists of the ciphertext output from the AEAD
encryption operation.  The length of the plaintext is greater than
TLSPlaintext.length due to the inclusion of TLSPlaintext.type and any
padding supplied by the sender.  The length of the AEAD output will
generally be larger than the plaintext, but by an amount that varies
with the AEAD algorithm.  Since the ciphers might incorporate
padding, the amount of overhead could vary with different lengths of
plaintext.  Symbolically,
Paragraph (version A):
An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion of
greater than 255 bytes.  An endpoint that receives a record from its
peer with TLSCipherText.length larger than 2^14 + 256 octets MUST
terminate the connection with a "record_overflow" alert.  This limit
is derived from the maximum TLSPlaintext length of 2^14 octets + 1
octet for ContentType + the maximum AEAD expansion of 255 octets.
Paragraph (version B):
An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion
greater than 255 octets.  An endpoint that receives a record from its
peer with TLSCipherText.length larger than 2^14 + 256 octets MUST
terminate the connection with a "record_overflow" alert.  This limit
is derived from the maximum TLSPlaintext length of 2^14 octets + 1
octet for ContentType + the maximum AEAD expansion of 255 octets.
Paragraph (version A):
The sequence number is incremented after reading or writing each
record.  The first record transmitted under a particular set of
traffic keys record key MUST use sequence number 0.
Paragraph (version B):
The sequence number is incremented after reading or writing each
record.  The first record transmitted under a particular set of
traffic keys MUST use sequence number 0.
Paragraph (version A):
The padding sent is automatically verified by the record protection
mechanism: Upon successful decryption of a TLSCiphertext.fragment,
the receiving implementation scans the field from the end toward the
beginning until it finds a non-zero octet.  This non-zero octet is
the content type of the message.  This padding scheme was selected
because it allows padding of any encrypted TLS record by an arbitrary
size (from zero up to TLS record size limits) without introducing new
content types.  The design also enforces all-zero padding octets,
which allows for quick detection of padding errors.
Paragraph (version B):
The padding sent is automatically verified by the record protection
mechanism: upon successful decryption of a
TLSCiphertext.encrypted_record, the receiving implementation scans
the field from the end toward the beginning until it finds a non-zero
octet.  This non-zero octet is the content type of the message.  This
padding scheme was selected because it allows padding of any
encrypted TLS record by an arbitrary size (from zero up to TLS record
size limits) without introducing new content types.  The design also
enforces all-zero padding octets, which allows for quick detection of
padding errors.