F08-RI: Yes
Rationale
With nonempty DTLS Connection IDs negotiated in both directions, the existing protected association can accept a record arriving on a changed UDP path. The pinned implementation retains the WOLFSSL association and promotes a pending peer address only after record deprotection and a newest-record check; it does not need a new handshake for that transition.
Assessment method
Source/API provenance and bounded documentary witness; no execution
Source context
Pinned wolfSSL source and DTLS 1.3 specification
Outstanding qualification
Explicit optional-CID witness: enable DTLS 1.3/CID, verify negotiation, keep the object, keys, replay/epoch state and timeout alive, and provide each candidate source address through the pending-peer receive path. Do not blindly call set_peer on an unauthenticated packet. Test wrong CID, invalid authentication, replay and stale records; no execution occurred. This is DTLS association continuity, not a reliability/ordering guarantee for application datagrams or proof of complete radio/RPL mobility.
Public sources
- https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/src/internal.c
- https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/wolfssl/ssl.h
- https://raw.githubusercontent.com/wolfSSL/wolfssl/eb113cac674a9f7da61a70a6307a7db959753ccf/src/dtls13.c
- https://www.rfc-editor.org/rfc/rfc9147.html
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round271-sources.json