Repository navigation
feat(application): dissect DTLS 1.3 unified-header records that carry a connection ID #2625
Description
This is a follow-up from #2515, the owner's option 1(a) there. DTLS 1.3 unified-header records that carry a connection ID (RFC 9147 §4, the C bit) stay Raw, because their CID length is not on the wire. Reuse #2515's DTLSContext to supply it. IDs that DTLS 1.3 sends later inside the encrypted NewConnectionId message cannot be learned from the capture, so those come only from the caller.
Blocked: this builds on #2515's DTLSContext. It unblocks when #2515's PR merges.
Activity
JarryShaw commentedon Nov 2, 2026
#2515 has merged as #2631, so
DTLSContextis onmain. Still blocked, but the condition has changed: #2622 also editsdtls.pyand is waiting to open as a PR. This unblocks when #2622 merges.JarryShaw commentedon Nov 2, 2026
#2622 has merged as #2634, so
dtls.pyis free. Unblocked. It goes to a worker as soon as host load allows: the record-layer CID path for DTLS 1.3 unified headers, reusingDTLSContext.JarryShaw commentedon Nov 2, 2026
DTLS 1.3 connection-ID records are done locally, and a Sonnet review is running. They resolve through #2631's
DTLSContextmatcher, which now handles both record types. The test vectors are a real wolfSSL 5.9.4 DTLS 1.3 CID exchange, and tshark agrees on every record. NewConnectionId IDs can come only from the caller, and that limit is documented. Your #2515 rulings are kept and tested.Needs deciding: every unified-header record's
infogains acidkey, which isNonewhen the C bit is clear.lengthbeingNonewhen the L bit is clear, and keeps one data model for one header.Recommendation: 1. The branch implements 1 unless you choose otherwise.
feat(application): dissect DTLS 1.3 connection-ID unified-header reco…
feat(application): dissect DTLS 1.3 connection-ID unified-header reco…
JarryShaw commentedon Nov 2, 2026
Take 1
JarryShaw commentedon Nov 2, 2026
The owner chose 1, paraphrased: every unified-header record's
infokeeps acidkey, which isNonewhen the C bit is clear. That mirrorslength, and there is one data model for one header.#2643 already implements this and is good to go at
d86dbdd1f. This settles the open question, soneeds: decisioncomes off. #2643's red 3.15 leg is the re-export failure inherited frommain, which #2641 fixes.feat(application): dissect DTLS 1.3 connection-ID unified-header reco…
feat(application): dissect DTLS 1.3 connection-ID unified-header reco…
docs(changelog): fold DTLS 1.3 connection IDs and the 1.5.0 HTTP role…