Summary

  • A CRYPTO frame is a contiguous offset-and-length slice of one encryption level’s reliable handshake byte stream.
  • Frame and packet boundaries do not establish a complete TLS message, flight, certificate result, key transition, handshake completion, or application readiness.
  • Evidence should keep QUIC carriage, TLS parsing, key state, retransmission, and later completion receipts in separate fields.

A packet observer sees a protected packet and, after successful packet protection removal, finds one CRYPTO frame. The tempting conclusion is that the frame represents a complete ClientHello or Finished message. That conclusion outruns the evidence. QUIC identifies the frame by an offset and length within the CRYPTO byte stream belonging to one encryption level. It does not label the slice as a TLS message, and it does not add a semantic end marker.

The frame fits wholly inside one QUIC packet. The handshake data does not therefore become packet-sized. A TLS handshake message or flight may cross several CRYPTO frames and several packets. Conversely, one frame may begin or end in the middle of a TLS message. When lost cryptographic information is sent again, QUIC reframes the bytes in new CRYPTO frames and protects them with the keys of the same encryption level as the original bytes. The new packet or frame is not proof of a second TLS message or a replay; it is new transport packaging for the needed byte range.

The word “stream” needs careful qualification. Each encryption level has its own CRYPTO sequence, with offsets beginning at zero. Initial, Handshake, and 1-RTT packets can carry CRYPTO; 0-RTT packets cannot. Equal offsets in different levels are not adjacent positions in one connection-wide handshake. QUIC puts received bytes into the proper per-level sequence, buffers gaps and data for a future level when necessary, and delivers newly contiguous bytes to TLS in order. TLS then performs its own buffering and complete-message parsing.

That division creates several distinct observations. A packet type is not an encryption-level conclusion by itself unless the relevant QUIC mapping is recorded. A packet-number space is not a TLS parse state. Removing QUIC packet protection is not the same as a successful TLS parse. A CRYPTO offset and length show the transported range, while a privacy-safe digest can help correlate observations without retaining handshake content. The contiguous range received, the gaps still held by QUIC, and the range delivered to TLS are different ledger entries.

TLS may consume bytes incrementally or wait until a complete message or flight is available. Key availability is an output of processing TLS input; it is not proved merely by seeing a CRYPTO frame. Nor does the frame prove that a key has been installed. If TLS advances to a higher encryption level while earlier data at the prior level remains unconsumed, the endpoint treats that condition as PROTOCOL_VIOLATION. Initial and Handshake data are discarded when the corresponding packet-number-space keys are discarded. Neither lifecycle event supplies a semantic boundary for an individual TLS message.

CRYPTO carries only TLS handshake messages; TLS alerts map to QUIC CONNECTION_CLOSE error codes, and TLS application data or other TLS content types cannot travel in CRYPTO frames. CRYPTO is not a flow-controlled application stream. It has no stream ID, FIN, explicit stream end, or semantic completion marker. Implementations must support at least 4096 bytes of out-of-order CRYPTO data, while an excessive largest offset can lead to FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. Those facts describe transport handling and resource protection, not the success of certificate validation or the readiness of an application.

A reliable evidence model therefore asks what each layer actually witnessed. At the packet layer, record QUIC version, packet type, packet-number space, encryption level, packet protection result, and packet number. At the frame layer, record offset, length, and a privacy-safe digest. At the reassembly layer, record the per-level contiguous range and gaps. At the delivery layer, record what range QUIC handed to TLS and when. Only after TLS parses a complete message should a message type be recorded.

Certificate validation, alerts, key availability, key discard, TLS handshake completion, QUIC handshake confirmation, and application readiness require their own receipts.

This boundary is also why nearby questions must not be collapsed into this one. TR-048 concerns handshake confirmation and application readiness, later states than the byte-container boundary here. TR-049 concerns multiple QUIC packets coalesced in one UDP datagram, not the semantic extent of a CRYPTO slice. TR-045 concerns what packet acknowledgment proves. TR-056 concerns packet-number reconstruction and packet-number spaces. TR-063 concerns preferred-address migration after the handshake path, not CRYPTO framing. Keeping those five dimensions separate prevents a plausible observation from becoming a false claim.

The practical rule is simple: treat CRYPTO as a reliable transport container for handshake bytes. Require a TLS parser receipt before asserting a complete message or flight; separate certificate-validation and key-transition evidence; and require independent completion, confirmation, and readiness receipts for higher claims. That discipline is not a demand made by QUIC telemetry. It is an operational recommendation for making claims no stronger than the evidence.