Support DTLS1.3 downgrade when server supports CID #7841
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
With --enable-dtlscid, a client sending a Client Hello to a DLTS1.2 server that supports CID, the server provides the appropriate CID and assumes that CID has been negotiated.
However, in the case of MbedTLS, it then rejects packets that do not match its expected CID from the client - as wolfSSL no longer sends the CID as it is not DTLS1.2.
https://datatracker.ietf.org/doc/html/rfc9147#section-4
If a Connection ID is negotiated, then it MUST be contained in all datagrams.
This fix drops the CID if a Hello Verify Request is received, so the second Client Hello does not include the CID.
https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1
When responding to a HelloVerifyRequest, the client MUST use the same parameter values (version, random, session_id, cipher_suites, compression_method) as it did in the original ClientHello.
Dropping the CID extension does not violate this.
Testing
Tested against a MbedTLS server with CID support, and enabled CID for the wolfSSL client.
Checklist