Repository navigation
feat(application): dissect DTLS 1.3 connection-ID unified-header records - #2643
Conversation
|
GOOD TO GO at
The fix round adds two things the review asked for. The fit now needs room for the 16-octet record-number sample, which removes the prefix ambiguity. Tests now kill the two mutants that survived, M5 ( This branch conflicts with #2638 in |
a080737 to
e919d1c
Compare
|
Fix round and rebase:
The patch-id changed and the change touches a shared harness, so the label is |
|
NEEDS CHANGES at
CI on this head is cancelled until the fix round lands. |
e919d1c to
d86dbdd
Compare
|
Fix round:
The label is |
|
GOOD TO GO at
|
|
Coverage: 94.08% -- tests failure, so this is partial (unit tier, Python 3.15,
Per-file detail: the |
|
Resolve conflicts |
|
The owner asked for the conflicts to be resolved. A rebase onto |
…rds (#2625) - A unified header with the C bit set stayed Raw: its CID length is not on the wire. DTLSCiphertext gains a cid, read with the length DTLSContext finds, and None when C is clear. - DTLSContext.match takes the unified layout, so both CID record types go through the one matcher: learned or caller IDs by value, then cid_length. A unified record must leave room for its record-number sample, so a shorter ID is not misread as a longer one; tls12_cid is unchanged. - An unknown length keeps the record Raw, quietly. make() takes cid for a unified header; IDs a NewConnectionId issues come from the caller only. - Schema round trip: an override pins the bit-field subfields it sets, so the case sets C; guards check the pin and that PARSE_CONTEXT is read. Tests: wolfSSL 5.9.4 capture checked with tshark 4.6.9, RFC 9147 vectors.
d86dbdd to
3cf3a27
Compare
|
Conflicts resolved, rebased onto
The verdict stays good to go. |
…s into 1.6.0 (#2449) - Folded into the TLS/DTLS entry: DTLSContext resolves a unified-header record's connection ID as a tls12_cid one's, an ID NewConnectionId issues coming only from the caller; every unified-header record's info carries cid, None when C is clear, the one-data-model ruling on #2625; make() takes cid (#2643). The entry drops the stale "stays Raw" for those records. - 1.5.0's httpv1.HTTP and httpv2.HTTP roles point at HTTPv1 and HTTPv2, renamed by #2544, so the nitpicky build no longer warns on them; 1.5.0's text unchanged. - No entry for the test-only #2644. - CHANGELOG.md regenerated; util/changelog_md.py --check passes.
make pylint,make mypy,make isort)make testpasses, and a test case covers the changeWhat is the purpose of your pull request?
feat— a new featureDescription of your pull request and other information
DTLS 1.3 unified-header records with the C bit set (RFC 9147 §4) now parse as DTLS 1.3 layers. Their connection-ID length comes from #2631's
DTLSContext, in one of two ways:cid_length.The matcher is #2631's, extended rather than duplicated. A fit needs room for the 16-octet record-number sample, so a shorter learned ID is not misread as a longer one. IDs sent later in DTLS 1.3's encrypted
NewConnectionIdcan come only from the caller; this is documented. With no known length, the record staysRawquietly. The owner's #2515 rulings hold: memory is per instance, andcid_lengthis a single value.Test vectors come from a real wolfSSL 5.9.4 DTLS 1.3 CID exchange, and tshark agrees on every record. Both round trips are byte-exact. The only change to existing output is a
cid: Nonekey on unified-header records without a CID; that is option 1 of the open question on #2625. A Sonnet cross-review returned GOOD TO GO, and its hardening and two mutant-killing tests are folded in.Closes #2625