Repository navigation
feat(application): dissect RFC 9146 connection-ID DTLS records #2515
Description
Follow-up split out of #2437 (owner's choice, option 1).
DTLS records that use RFC 9146 connection IDs (content type tls12_cid, 25) fall back to Raw on main (#2441). RFC 9146 §4 places the CID after the sequence number, and its length is negotiated, not on the wire. So the parser needs the negotiated CID length (from the connection_id extension in the handshake), or an explicit caller-supplied length.
Scope: dissect tls12_cid records' header (epoch, sequence number, CID, length) and keep the encrypted payload as data. Take the CID length from the handshake when the same capture carries it, and otherwise from a caller-supplied value. Round-trips stay byte-exact.
Blocked: #2496 is reworking pcapkit/protocols/application/dtls.py right now. This unblocks when #2496's PR merges.
Activity
JarryShaw commentedon Nov 1, 2026
Unblock condition, stated so it can be checked: #2528 merges. It is reworking
pcapkit/protocols/application/dtls.py.JarryShaw commentedon Nov 1, 2026
#2528 merged, but DTLS record parsing is next being changed by #2535, which chains every record in a datagram. Blocked: this unblocks when #2535's PR merges, so that connection-ID records build on the chained layout.
JarryShaw commentedon Nov 2, 2026
#2603 has merged, so DTLS chains every whole record in a datagram. Unblocked. A worker is on the connection-ID records, building on that chaining and on the
ProtocolBasevalue helpers from #2595.JarryShaw commentedon Nov 2, 2026
The connection-ID records are done locally and a Sonnet review is running.
tls12_cidrecords parse as DTLS 1.2 layers, chained with the other records in their datagram. The connection ID length comes from the IDs the capture's own ClientHello and ServerHello negotiated, matched by value so the direction does not matter. A caller can also supply aDTLSContext. With no known length, the record staysRaw, quietly. The test vectors are a real Mbed TLS exchange, pinned against tshark's dissection. All other DTLS output is unchanged.Needs deciding. The branch implements the recommendations, so it proceeds unless you choose otherwise.
Raw.DTLSContext, with IDs from DTLS 1.3's encrypted NewConnectionId supplied by the caller.DTLSContextkeeps the IDs it learns, so reusing one instance carries them into the next extraction.cid_lengthis a single value.DTLSContext(*ids), which handles different lengths per direction.JarryShaw commentedon Nov 2, 2026
JarryShaw commentedon Nov 2, 2026
The owner chose 1(a), 2(a) and 3(a), paraphrased: DTLS 1.3 CID records go to a follow-up, filed as #2625 and blocked on this one. A caller's
DTLSContextkeeps the IDs it learns, and this is documented.cid_lengthstays a single value. These are what the branch already implements, so nothing changes. It opens as a PR once the Sonnet review returns and the Actions queue drops below 20.JarryShaw commentedon Nov 2, 2026
DTLSContext's memory should go per instance. New instance should not still carry the historical context. It's that's what we're implementing.JarryShaw commentedon Nov 2, 2026
Owner ruling, paraphrased:
DTLSContext's memory belongs to the instance. A new instance starts with no learned IDs, and nothing carries over through shared state. An extraction run without a caller's context gets a fresh instance of its own, so consecutive or concurrent extractions never share IDs. A caller who reuses an instance keeps what that instance learned. The fix round is checking the implementation against this and adding tests that fail if a shared store comes back.fix(tests): import pcapkit before the hook sentinels go in (#2637)
fix(protocols): re-export the DTLS connection-ID data and schema names (