One direction's record protection: its suite, traffic keys, and the sequence number that keepstheir nonces apart. RFC 8446 §5.3 restarts the sequence at zero on every key change.
Open one whole TLSCiphertext record — header included, since RFC 8446 §5.2makes that header the AEAD's additional data — into the content type andcontent sealed inside, advancing the sequence number.
A tag that does not verify is a BadRecordMac and the sequence does notmove, because §5.2 ends the connection there.
Other keeps a content type the RFC does not define rather than losing it,but the parser refuses one: an unknown type is an UnexpectedMessage, notsomething to skip past.
The fixed part of the nonce the key block gives each direction: GCM's and CCM's four-octet salt,ChaCha20-Poly1305's twelve, and nothing for CBC, whose IV goes out with each record.
The largest TLSCiphertext encrypted_record (RFC 8446 §5.2): 2^14 + 256 — thefragment limit plus the room the inner content type, the padding and theAEAD tag need.
The per-record AEAD nonce (RFC 8446 §5.3): the 64-bit sequence number, big-endian and left-padded with zeros to the IV's length, XORed with the staticwrite IV.
The IV never changes, so the sequence number alone is what keeps two recordsunder one key from ever sharing a nonce.
Derive a direction's record-protection key and IV from its traffic secret(RFC 8446 §7.3).
QUIC expands the same secret under "quic key"/"quic iv" and adds aheader-protection key (RFC 9001 §5.1); over TCP the labels are bare andthere is no header to protect.
Split a TLSInnerPlaintext back into its content type and content(RFC 8446 §5.2).
Scan back over the zero padding to the last non-zero octet, which is thetype. An inner plaintext of nothing but zeros names no type at all, which§5.2 makes an UnexpectedMessage rather than an empty record.