Draft: draft-ietf-tls-tls13

Commentary: This is a big improvement over the previous proposed methods , by the way . I suggest filing a followup PR for your comments , as it looks like this has already merged .
Paragraph (version A):
Note in particular that the length of a record is not protected by
encryption.  If this information is itself sensitive, application
designers may wish to take steps (e.g., padding, cover traffic) to
minimize information leakage.
Paragraph (version B):
Note in particular that the length of a record or absence of traffic
itself is not protected by encryption unless the sender uses the
supplied padding mechanism - see record-padding for more details.
Paragraph (version A):
Implementations MUST NOT send zero-length fragments of Handshake or
Alert types.  Zero-length fragments of Application data MAY be sent
as they are potentially useful as a traffic analysis countermeasure.
Paragraph (version B):
Implementations MUST NOT send zero-length fragments of Handshake or
Alert types, even if those fragments contain padding.  Zero-length
fragments of Application data MAY be sent as they are potentially
useful as a traffic analysis countermeasure.
Paragraph (version A):
The AEAD encrypted form of TLSPlaintext.fragment +
TLSPlaintext.type, where "+" denotes concatenation.
Paragraph (version B):
An arbitrary-length run of null bytes (uint8 with value 0) may
appear in the cleartext after the type field.  This provides an
opportunity for senders to pad any TLS record by a chosen amount
as long as the total stays within record size limits.  See record-
padding for more details.
Paragraph (version B):
The AEAD encrypted form of TLSPlaintext.fragment +
TLSPlaintext.type + zeros, where "+" denotes concatenation.
Paragraph (version A):
The AEAD output consists of the ciphertext output by the AEAD
encryption operation.  The length of the plaintext is one greater
than TLSPlaintext.length due to the inclusion of TLSPlaintext.type.
The length of aead_output will generally be larger than the
plaintext, but by an amount that varies with the AEAD cipher.  Since
the ciphers might incorporate padding, the amount of overhead could
vary with different TLSPlaintext.length values.  Symbolically,
Paragraph (version B):
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
however much padding is supplied by the sender.  The length of
aead_output will generally be larger than the plaintext, but by an
amount that varies with the AEAD cipher.  Since the ciphers might
incorporate padding, the amount of overhead could vary with different
lengths of plaintext.  Symbolically,
Paragraph (version B):
All encrypted TLS records can be padded to inflate the size of the
TLSCipherText.  This allows the sender to hide the size of the
traffic from an observer.
Paragraph (version B):
When generating a TLSCiphertext record, implementations MAY choose to
pad.  An unpadded record is just a record with a padding length of
zero.  Padding is a string of null bytes (uint8 with value 0)
appended to the ContentType field before encryption.  Implementations
MUST set the padding octets to all zeros before encrypting.
Paragraph (version B):
Application Data records can be all padding if the sender desires.
This permits generation of plausibly-sized cover traffic in contexts
where the presence or absence of activity may be sensitive.
Implementations MUST NOT send Handshake or Alert records that are all
padding.
Paragraph (version B):
The padding sent will be authenticated 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 uint8.  This non-zero octet is
the content type of the message.
Paragraph (version B):
Implementations MUST limit their scanning to the cleartext returned
from the AEAD decryption.  If a receiving implementation does not
find a non-zero octet in the cleartext, it should treat the record as
having an unexpected ContentType, sending an "unexpected_message"
alert.
Paragraph (version B):
The presence of padding does not change the overall record size
limitations - the full fragment plaintext may not exceed 2^14 octets.
Paragraph (version B):
Versions of TLS prior to 1.3 did not enable padding of any record at
the TLS level.  The padding scheme introduced in TLS 1.3 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 should avoid any risk of sending uninitialized memory as
padding.
Paragraph (version B):
Selecting a padding policy that suggests when and how much to pad is
a complex topic, and is beyond the scope of this specification.  If
the application layer protocol atop TLS permits padding, it may be
preferable to pad application_data TLS records within the application
layer.  Padding for encrypted handshake and alert TLS records must
still be handled at the TLS layer, though.  Later documents may
define padding selection algorithms, or define a padding policy
request mechanism through TLS extensions or some other means.