[Frauschi]

Description

A client with TLS 1.3 or DTLS 1.3 as its minimum version still offered the RFC 7027 brainpool codepoints (26/27/28). The minDowngrade check was always true, because DTLS minors count down.

1. TLSX_PreTls13Reachable() offers the RFC 7027 codepoints only when supported_versions would also offer a version before 1.3, taking the minimum version and the version masks into account. A TLS 1.3 server no longer sends them in EncryptedExtensions.
2. The DTLS version now follows the version mask, as in OpenSSL 4.1 (the first release with DTLS 1.3, where SSL_OP_NO_DTLSv1_3 is the SSL_OP_NO_TLSv1_3 bit). Before, WOLFSSL_OP_NO_TLSv1_3 dropped DTLS 1.3 from supported_versions but left the SSL on DTLS 1.3, with a TLS 1.3 key_share and the TLS 1.3-only groups.
   • wolfSSL_set_options(), wolfSSL_set_max_proto_version() and wolfSSL_set_session() move a DTLS SSL that may downgrade to the newest version the mask and minimum allow. wolfSSL_connect(), wolfSSL_accept() and their _TLSv13 variants check the accumulated mask and minimum again when the handshake starts, so the order of the calls does not matter. The _TLSv13 variants hand a DTLS SSL below 1.3 to the legacy handshake.
   • The min and max proto version setters handle DTLS: DTLS1_VERSION and DTLS1_2_VERSION cap a DTLS SSL, DTLS1_3_VERSION is accepted, a version of 0 no longer caps a DTLS CTX at DTLS 1.2 or stores a TLS-numbered minimum (which made a DTLS 1.3 client send an empty supported_versions), and a TLS minimum on a DTLS object maps to the DTLS version with the same mask bit.
   • A DTLS server picks only allowed versions from the client's supported_versions, and checks the version it steps down to for a ClientHello without one. A DTLS client refuses a server version its mask does not allow.
   • Methods that cannot downgrade keep their version, as OpenSSL's fixed-version methods ignore the mask.
3. ECH: the inner ClientHello no longer pulls in the outer brainpool list. The outer hello keeps its own groups in the same extension position as a GREASE ECH hello, and a TLS 1.2 or older ServerHello switches back to them. After a HelloRetryRequest, both lists stay as they were in the first hello. A pre-1.3 ServerHello after a HelloRetryRequest that accepted ECH now fails with illegal_parameter (RFC 9849 section 6.1.5).

Behavior changes:

• A downgrade-capable DTLS SSL with no allowed version left fails in wolfSSL_connect()/wolfSSL_accept() with VERSION_ERROR, or in wolfSSL_new() when the mask comes from the CTX. Before, it went on and negotiated a masked version or failed later.
• A session whose DTLS version the mask no longer allows is not resumed.
• New SSL_OP_NO_DTLSv1, SSL_OP_NO_DTLSv1_2 and SSL_OP_NO_DTLSv1_3 aliases, with OpenSSL's values. SSL_OP_NO_DTLSv1 is WOLFSSL_OP_NO_TLSv1_1, the bit wolfSSL masks DTLS 1.0 with, so on a TLS object it masks TLS 1.1 rather than TLS 1.0.
• wolfSSL_set_max_proto_version() with a DTLS version on a DTLS SSL now caps it; before it did nothing. wolfSSL_CTX_get_min_proto_version() reports DTLS minimums instead of 0.
• A DTLS version as the minimum of a TLS SSL or CTX (including wolfSSL_(CTX_)SetMinVersion(), which returns BAD_FUNC_ARG), or as the maximum of a TLS SSL, now fails, as it already did for the CTX maximum. A TLS version as the maximum of a DTLS CTX still fails, but no longer masks DTLS 1.3 on the way. DTLS1_3_VERSION as the maximum of a fixed-version DTLS 1.2 or 1.0 CTX fails instead of turning it into DTLS 1.3.

#11756 touches the same check in TLSX_DefaultGroupAllowed(). Whichever PR lands second has to carry it over.

Testing

• test_TLSX_SupportedCurve_brainpool_downgrade: client offers across min versions, methods and masks (TLS and DTLS), the TLS 1.3 server reply, the ECH inner and outer lists, the outer extension order against GREASE ECH, and HelloRetryRequest with ECH accepted and rejected.
• test_dtls13_no_tls13_option: the DTLS mask on the client and server, through the SSL and the CTX, with up to three separate option calls, cases with no version left, the cipher suites after a move, wolfSSL_negotiate(), a DTLS 1.2-only peer on either side, a supported_versions list with only DTLS 1.2, sessions set before or after the mask, early data, EMS after a dropped resumption, an SNI callback that sets the mask mid-ClientHello, a minimum set after the mask, the SSL and CTX min and max proto versions including 0, and the _TLSv13 entry points on an SSL already at DTLS 1.2.
• test_tls13_ech_hrr_tls11_server_hello: a TLS 1.1 ServerHello after an ECH-accepting HelloRetryRequest, and a TLS 1.1 fallback without one.

[github-actions]

MemBrowse Memory Report · Explore what changed →

gcc-arm-cortex-m3

• FLASH: .text +44 B (+0.0%, 130,861 B / 262,144 B, total: 50% used)

gcc-arm-cortex-m4

• FLASH: .text +64 B (+0.0%, 207,280 B / 262,144 B, total: 79% used)

gcc-arm-cortex-m4-dtls13

• FLASH: .text +704 B (+0.4%, 195,032 B / 1,048,576 B, total: 19% used)

gcc-arm-cortex-m4-openssl-compat

• FLASH: .text +64 B (+0.0%, 793,628 B / 1,048,576 B, total: 76% used)

gcc-arm-cortex-m4-pq

• FLASH: .text +64 B (+0.0%, 309,136 B / 1,048,576 B, total: 29% used)

gcc-arm-cortex-m4-rsa-only

• FLASH: .text +64 B (+0.0%, 340,488 B / 1,048,576 B, total: 32% used)

gcc-arm-cortex-m4-tls12

• FLASH: .text +64 B (+0.0%, 131,665 B / 262,144 B, total: 50% used)

gcc-arm-cortex-m7

• FLASH: .text +64 B (+0.0%, 207,280 B / 262,144 B, total: 79% used)

gcc-arm-cortex-m7-pq

• FLASH: .text +64 B (+0.0%, 310,032 B / 1,048,576 B, total: 30% used)

gcc-arm-cortex-m7-tls13

• FLASH: .text +64 B (+0.0%, 246,626 B / 262,144 B, total: 94% used)

zephyr-frdm_rw612

• FLASH: log_const_area -8 B, rodata -8 B, text +160 B (+0.1%, 282,608 B / 67,108,864 B, total: 0% used)

No memory changes detected for:

• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls13
• stm32-sim-stm32h753

---

_{Catch memory regressions in CI with MemBrowse. Free for open source.}

[Copilot]

🟡 Changes recommended

DTLS downgrade handling can bypass mandatory PSK enforcement, select a compiled-out protocol, and leave a disabled version negotiable after separate option calls.

3 open issues

• Honor PSK-required downgrade restrictions at the SSL level · New
• Guard DTLS 1.2 selection when TLS 1.2 is compiled out · New
• Reevaluate DTLS versions against accumulated option masks · New

What changed in this PR

This PR aligns brainpool group advertising with reachable TLS/DTLS versions and separates ECH inner and outer group lists.

Changes:

• Filter legacy brainpool codepoints using minimum versions and protocol masks.
• Add DTLS downgrade handling when TLS 1.3 is disabled.
• Preserve ECH group lists through fallback and HelloRetryRequest, with regression tests.

File	Description
wolfssl/​internal.h	Declare the DTLS downgrade helper.
tests/​api/​test_tls_ext.h	Register the brainpool regression test.
tests/​api/​test_tls_ext.c	Test brainpool offers, ECH fallback, and retries.
tests/​api/​test_dtls.h	Register the DTLS version-mask test.
tests/​api/​test_dtls.c	Test SSL- and CTX-level DTLS downgrade behavior.
tests/​api.c	Add brainpool coverage to the API suite.
src/​tls.c	Filter brainpool groups and separate ECH lists.
src/​ssl.c	Apply DTLS fallback when TLS 1.3 is masked.
src/​internal.c	Select DTLS fallback versions and restore ECH outer extensions.

_{Review effort: Balanced}

[Frauschi]

@wolfSSL-Fenrir-bot review balanced

[Frauschi]

@claude review

[claude]

I reviewed this PR and didn't find any bugs. It changes TLS/DTLS version downgrade and ECH ClientHello construction in a crypto library, so a human look would still be worthwhile.

What was reviewed:

• TLSX_PreTls13Reachable() replacing the always-true minDowngrade check: DTLS minors are compared with versionIsLessEqual, and the mask checks are guarded by OPENSSL_EXTRA/HAVE_WEBSERVER/WOLFSSL_WPAS_SMALL.
• Dtls13DowngradeMinor() in the CTX path (SetSSL_CTX_CheckVersion, which returns VERSION_ERROR when no version is left) and in the wolfSSL_set_options path, plus its WOLFSSL_NO_TLS12/NO_OLD_TLS guards.
• ECH: splitting supported_groups between the inner and outer hello, not compressing extensions that ech->extensions overrides, skipping the split after an HRR, and the new TLSX_EchReplaceExtensions call when a ServerHello picks TLS 1.2 or older.

Extended reasoning...

The change touches TLS/DTLS protocol-version negotiation (src/internal.c, src/ssl.c), how the default supported_groups list is built, and how the ECH inner and outer ClientHello extensions are built (src/tls.c), and it adds about 640 lines of tests. That is security-sensitive handshake code: version downgrade logic and ECH privacy behavior. The bug hunt ran until it stopped finding anything and reported no findings. Earlier Copilot inline comments on ssl.c and internal.c were resolved only by the PR author, after follow-up commits. Because of the protocol-level scope and the many feature-macro combinations, this should get a human review rather than an automatic approval.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #11857

Scan targets checked: wolfssl-src, wolfssl-bugs
Not reviewed (no scan target covers them): tests/api/test_dtls.h, tests/api/test_tls_ext.h
Coverage: 3 of 7 in-scope changed file(s) opened by the reviewer; not opened: tests/api.c, tests/api/test_dtls.c, tests/api/test_tls_ext.c, wolfssl/internal.h

Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Reported findings require changes before merge.

Review tier: Balanced

[julek-wolfssl]

Openssl doesn't use SSL_OP_NO_TLSv1_3 for DTLS. Why are we allowing this?

[Frauschi]

OpenSSL does now. 4.1, the first release with DTLS 1.3, defines SSL_OP_NO_DTLSv1_3 as SSL_OP_BIT(29), the same bit as SSL_OP_NO_TLSv1_3, and uses it as the mask of the DTLS 1.3 methods (ssl/methods.c). DTLS_method() picks its version in ssl_get_min_max_version() when the handshake starts, skipping masked versions, so SSL_OP_NO_DTLSv1_3 gives DTLS 1.2 there.

wolfSSL master already did half of this: TLSX_SupportedVersions_GetSize() drops DTLS 1.3 from supported_versions under WOLFSSL_OP_NO_TLSv1_3, but the SSL stayed on DTLS 1.3 and still sent a TLS 1.3 key_share and the TLS 1.3-only groups. The PR now follows OpenSSL. wolfSSL_set_options() and wolfSSL_set_session() move the version straight away. wolfSSL_connect()/wolfSSL_accept() and the _TLSv13 entry points check the accumulated mask again when the handshake starts (DtlsCheckVersionMask()), so the order of the calls doesn't matter. On the server, the supported_versions parse only picks versions the mask allows. I also added SSL_OP_NO_DTLSv1_2 and SSL_OP_NO_DTLSv1_3, which use the same bits as in OpenSSL. I left out SSL_OP_NO_DTLSv1: OpenSSL defines it as the SSL_OP_NO_TLSv1 bit, while wolfSSL masks DTLS 1.0 with WOLFSSL_OP_NO_TLSv1_1, so the alias would behave differently.

[julek-wolfssl]

Thanks, the OpenSSL 4.1 behavior checks out.

On SSL_OP_NO_DTLSv1: WOLFSSL_OP_NO_TLSv1_1 is 0x04000000, bit 26. That’s the same value OpenSSL uses for SSL_OP_NO_DTLSv1. So #define SSL_OP_NO_DTLSv1 WOLFSSL_OP_NO_TLSv1_1 would match OpenSSL’s value and mask DTLS 1.0 the way wolfSSL does. The only difference is on a TLS context, where it would mask TLS 1.1 rather than TLS 1.0. Code that sets a DTLS option on a TLS context should be rare.

Without the alias, code ported from OpenSSL that uses SSL_OP_NO_DTLSv1 won’t compile. I’d add the alias and document the TLS-context difference. What do you think?

[Frauschi]

You're right, I had the bits wrong. wolfSSL's WOLFSSL_OP_NO_TLSv1_1 is OpenSSL's SSL_OP_NO_TLSv1/SSL_OP_NO_DTLSv1 value, so the alias matches OpenSSL's value and wolfSSL's DTLS 1.0 masking. Added SSL_OP_NO_DTLSv1 as WOLFSSL_OP_NO_TLSv1_1, and the wolfSSL_CTX_set_options() doc table now lists the three DTLS options, with the TLS 1.1 effect on a TLS object called out. test_dtls13_no_tls13_option uses the new name.

[julek-wolfssl]

Also here.

[Frauschi]

This is now DtlsMaskVersion(), shared with the check at the start of the handshake. See the reply on internal.c for the OpenSSL 4.1 behavior it follows.

[sebastian-carpenter]

  HIGH-1: ECH split moves supported_groups to the front of the outer ClientHello, so real ECH can be told apart from GREASE ECH [BLOCK] (bug)
  File:       src/tls.c:16804-16814
  Function:   TLSX_EchSplitSupportedGroups
  Confidence: High

  `TLSX_EchSplitSupportedGroups` runs at the end of `TLSX_PopulateExtensions`, after ECH, key_share, psk_kex_modes and the rest have been pushed. It calls `TLSX_Remove(&ssl->extensions, TLSX_SUPPORTED_GROUPS, ...)` and then `TLSX_PopulateSupportedGroups(ssl, &ssl->extensions)`. `TLSX_UseSupportedCurve` creates the new node with `TLSX_Push`, which puts it at the head of `ssl->extensions`.

`TLSX_Write` walks the list from head to tail. Before this change, supported_groups was pushed early (around line 16859) and was written near the end of the ClientHello. After the split it is the head node, so it is written first.

When the outer hello is written, `TLSX_EchSwapExtensions` swaps nodes by type in place. The outer supported_groups therefore takes over the moved position too. The result: a ClientHello with real ECH (echConfigs set, brainpool built in, TLS 1.2 still reachable) has a different extension order than a GREASE-ECH or non-ECH ClientHello from the same client. A passive observer can spot real ECH from the order alone, which defeats the point of sending GREASE ECH (RFC 9849 §6.2).

Before this diff the outer SNI was swapped in place and the order matched GREASE. The CH1/CH2 comparison in `test_brainpool_ech_hrr` does not catch this, because both hellos come after the split.

  Code:
        ech = (WOLFSSL_ECH*)echX->data;
        ret = TLSX_PopulateSupportedGroups(ssl, &ech->extensions);
        if (ret == WOLFSSL_SUCCESS) {
            TLSX_Remove(&ssl->extensions, TLSX_SUPPORTED_GROUPS, ssl->heap);
            downgrade = ssl->options.downgrade;
            ssl->options.downgrade = 0;
            ret = TLSX_PopulateSupportedGroups(ssl, &ssl->extensions);
            ssl->options.downgrade = downgrade;
        }

  Recommendation: Leave the existing SUPPORTED_GROUPS node where it is in `ssl->extensions` and swap only its `data` for the TLS 1.3-only list built into a temporary list. `TLSX_SupportedCurve_CheckPriority` already swaps `data` this way. Also add a test that compares the extension type order of a real-ECH outer ClientHello with a GREASE-ECH ClientHello from the same configuration; `test_bp_parse_ch` can extract the type lists.

  MEDIUM-2: TLS 1.2 ServerHello ECH hook passes echAccepted, though the comment says the outer hello is answered [SUGGEST] (bug)
  File:       src/internal.c:36437-36442
  Function:   DoServerHello
  Confidence: Medium

  The new hook's comment says "A server negotiating TLS 1.2 or older answers the outer hello", but it calls `TLSX_EchReplaceExtensions(ssl, ssl->options.echAccepted)`.

`echAccepted` can only be 1 here after a HelloRetryRequest that accepted ECH. `tls13.c:5722` deliberately keeps `ech->extensions` for CH2 in that case. If the server then answers with a TLS 1.2 or lower ServerHello (for example the `wantDowngrade` path at `tls13.c:5863`, which runs before the HRR cipher-suite check), the client takes the accepted branch. It frees the outer extensions and continues with the inner ones; certificate verification also skips the public_name check because `echAccepted` is set.

The TLS 1.3 path treats "HRR accepted, ServerHello did not" as fatal (`tls13.c:5699`, RFC 9849 §6.1.5). The new hook is the natural place to enforce the same rule for the downgrade path, and as written it encodes the opposite of its own comment.

  Code:
    #if defined(WOLFSSL_TLS13) && defined(HAVE_ECH)
            /* A server negotiating TLS 1.2 or older answers the outer hello. */
            ret = TLSX_EchReplaceExtensions(ssl, ssl->options.echAccepted);
            if (ret != 0)
                return ret;
    #endif

  Recommendation: Pass 0 explicitly so the code matches the comment. Also reject the connection when `echAccepted` is already set, matching the TLS 1.3 ServerHello handling.

[Frauschi]

@sebastian-carpenter thanks, both fixed.

HIGH-1: confirmed, the re-pushed supported_groups ended up at the head of the list. TLSX_EchSplitSupportedGroups() now builds the inner list in a temporary list and swaps only the data into the existing node. The brainpool test now compares the outer ClientHello's extension order with a GREASE ECH one from the same config; that check failed before the fix.

MEDIUM-2: DoServerHello() now fails with illegal_parameter when a HelloRetryRequest in this handshake accepted ECH, and passes 0 otherwise. It keys on msgsReceived.got_hello_retry_request, so it covers both ways a pre-1.3 ServerHello gets there after an HRR: a TLS 1.1 or older one through the wantDowngrade path, and a TLS 1.2 one with extensions that repeats the HRR's cipher suite. Any other TLS 1.2 ServerHello already fails the HRR cipher suite check. test_tls13_ech_hrr_tls11_server_hello covers the first path.

[julek-wolfssl]

Can this still be reached after d3bf702? Now that SetSession() applies the mask, wolfSSL_new(), wolfSSL_set_options() and wolfSSL_set_session() all move the version straight away. So I’d expect wolfSSL_write_early_data() to see DTLS 1.2 and return BAD_FUNC_ARG before it sets earlyData. That’s also what test_dtls13_mask_early_data checks. Is there a path I’m missing where the version only changes here?

[Frauschi]

Yes, there was one: wolfSSL_set_max_proto_version(ssl, TLS1_2_VERSION) sets WOLFSSL_OP_NO_TLSv1_3 directly, without going through wolfSSL_set_options(), so the SSL stayed at DTLS 1.3. wolfSSL_write_early_data() then accepted the data, and this check moved the SSL to DTLS 1.2. Without the reset the handshake completed but the next wolfSSL_write() failed.

wolfSSL_set_max_proto_version() now moves the version straight away, and also handles DTLS1_VERSION, DTLS1_2_VERSION and DTLS1_3_VERSION; before, the DTLS versions left the mask alone, so capping a DTLS SSL had no effect. While testing that I hit two more version-0 problems on master and fixed them in the same commit: wolfSSL_(CTX_)set_min_proto_version(x, 0) stored a TLS-numbered minimum on a DTLS object, which made a DTLS 1.3 client send an empty supported_versions (the server answers decode_error), and wolfSSL_CTX_set_max_proto_version(ctx, 0) set a DTLS CTX's method to DTLS 1.2, because protoVerTbl stopped at DTLS1_2_VERSION. It now ends at DTLS1_3_VERSION.

The one path left is SetSSL_CTX() under WOLFSSL_WPAS_SMALL without OPENSSL_EXTRA: it copies the CTX mask but SetSSL_CTX_CheckVersion() is OPENSSL_EXTRA-only, so the version is not moved until the handshake starts. I kept the reset for that case. The hand-off now also runs for any DTLS SSL below 1.3 (see the Copilot thread below), and clearing earlyData there is right in either case.

[Copilot]

🟡 Changes recommended

A minimum-version call-order bypass and incorrect direct TLS 1.3 client dispatch remain unresolved.

2 open issues

• Enforce minimum DTLS version after downgrade masking · New
• Dispatch legacy handshake for pre-TLS 1.3 DTLS connections · New

3 resolved since last review

• Honor PSK-required downgrade restrictions at the SSL level
• Reevaluate DTLS versions against accumulated option masks
• Guard DTLS 1.2 selection when TLS 1.2 is compiled out

_{Review effort: Balanced}

[julek-wolfssl]

1. A DTLS cap on an SSL can't be undone (src/ssl.c:7794)
DtlsMaskVersion() only moves the version down. After set_max_proto_version(ssl, DTLS1_2_VERSION), calling it again with DTLS1_3_VERSION or 0 returns success but leaves the SSL on DTLS 1.2. set_options(SSL_OP_NO_DTLSv1_3)
followed by clear_options() does the same. Starting the walk from ctx->method->version.minor, as the resume path already does, would fix it.

2. A DTLS 1.3-only CTX can't be restored (src/ssl.c:5410)
On wolfDTLSv1_3_client_method(), capping at DTLS1_2_VERSION works. Setting it back to DTLS1_3_VERSION then fails (the !downgrade && minor != DTLSv1_3_MINOR guard), and 0 leaves it at 1.2.

3. With async crypto, accept can switch versions mid-ClientHello (src/ssl.c:7801)
The setters skip the mask walk once got_client_hello is set, but the DtlsCheckVersionMask() calls at the start of wolfSSL_accept/wolfSSL_accept_TLSv13 only check acceptState == ACCEPT_BEGIN. Suppose the SNI callback sets
SSL_OP_NO_DTLSv1_3 and key-share generation then returns WC_PENDING_E. On re-entry the SSL moves to DTLS 1.2 and is handed to the legacy accept with a DTLS 1.3 ClientHello half-processed. Not reproduced. Checking got_client_hello
inside DtlsMaskVersion() would cover every caller.

4. SSL and CTX setters disagree (src/ssl.c:5615 vs :5307)
On a DTLS SSL, wolfSSL_set_max_proto_version() accepts TLS constants. wolfSSL_CTX_set_max_proto_version() rejects them on a DTLS CTX. Is that intended?

5. Weak test (tests/api/test_dtls.c:16107)
test_dtls13_ctx_min_tls13 only asserts the version isn't DTLS 1.2. It should assert the exact expected result.

[Frauschi]

Thanks, all five are addressed in a6a5205:

1. Fixed. A higher wolfSSL_set_max_proto_version(), a maximum of 0, or a wolfSSL_clear_options() that clears a DTLS version bit now walks the mask down from ctx->method->version, so lifting a cap brings the SSL back up. The SSL keeps track of the bits its DTLS maximum added and only clears those, so an SSL_OP_NO_DTLSv1_2/_3 set by the application or the CTX stays in force. A resuming client keeps its session's version while the mask allows it.
2. Fixed by matching TLS: DTLS1_3_VERSION and 0 now raise a fixed DTLS method to DTLS 1.3, the same way fixed TLS methods are raised. That also means a wolfDTLSv1_2_method() CTX given a maximum of 0 ends up DTLS 1.3-only, as wolfTLSv1_2_method() does with TLS 1.3. If fixed methods should keep their own version, I'd do that as a follow-up for both TLS and DTLS.
3. Fixed. got_client_hello alone wasn't enough, since DoTls13ClientHello() clears it when it pends. DtlsMaskVersion() now skips while the first handshake is under way, which a new DtlsHandshakeStarted() works out from the connect/accept states, got_client_hello, buffered output and the async state (pending handler args included). A DTLS maximum that would change the mask fails in that window, since it could no longer take effect, and also after the handshake until wolfSSL_clear(). DoClientHello() gets its own mode, because it calls the check after got_client_hello is set to step down a ClientHello without supported_versions. I couldn't reproduce it without async. A cert setup callback that returns retry, the synchronous way to pause there, already hangs wolfSSL_accept() on master, which is a separate bug.
4. Not intended. The SSL setter now refuses TLS versions on a DTLS SSL, like the CTX setter and OpenSSL.
5. The test now checks that the client fails with VERSION_ERROR and stays on DTLS 1.3.