Change:
This is a big improvement over the previous proposed methods, by the way. NAME I suggest filing a followup PR for your comments, as it looks like this has already merged.

Discussion:
properties TLS does and does not provide and cannot safely rely on the latter. <del> 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. </del> <ins> 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. </ins> 5.1.

backward-compatibility. Implementations MUST NOT send zero-length fragments of Handshake or <del> Alert types.  Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure. </del> <ins> 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. </ins> 5.2.2.

application_data(23); /* see fragment.type _/ ProtocolVersion record_version = { 3, 1 }; /_ TLS v1.x */ uint16 length; aead- ciphered struct { opaque content[TLSPlaintext.length]; ContentType <del> type; } fragment; } TLSCiphertext; </del> <ins> type; uint8 zeros[length_of_padding]; } fragment; } TLSCiphertext; </ins> The outer opaque_type field of a TLSCiphertext record is always

The actual content type of the record. <ins> 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. </ins> The AEAD encrypted form of TLSPlaintext.fragment + <del> TLSPlaintext.type, where "+" denotes concatenation. </del> <ins> TLSPlaintext.type + zeros, where "+" denotes concatenation. </ins> The length of the per-record nonce (iv_length) is set to max(8 bytes, N_MIN) for the AEAD algorithm (see RFC5116 Section 4).  An AEAD

length of the data. The AEAD output consists of the ciphertext output by the AEAD <del> 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, </del> <ins> 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, </ins> In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value.  The

all, and that in that state we should send raw TLSPlaintext instead of sending a phony TLSCiphertext <ins> 5.2.3. 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. 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. 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. 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. 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. The presence of padding does not change the overall record size limitations - the full fragment plaintext may not exceed 2^14 octets. 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. 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. </ins> 6. TLS has three subprotocols that are used to allow peers to agree upon