lightway-core using DTLS 1.3

[julek-wolfssl]

Use the DTLS 1.3 implementation from wolfSSL for datagram connections.

Description

• Add configuration options to enable DTLS 1.3 in wolfSSL
• Change method to use DTLS 1.3
• Use wolfSSL_key_update_response() instead of wolfSSL_SSL_renegotiate_pending()
• Use quick timeouts to provide better efficiency for out of order messages.
• Tested using lightway-laser.

Motivation and Context

Adding DTLS 1.3 support for better performance and security.

How Has This Been Tested?

Tested using lightway-laser with docker-compose -f docker-compose.yml -f docker-compose-run.yml up --exit-code-from cli. These are first packets of the connection showing in the supported versions extension that DTLS 1.3 is being negotiatied.

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] All active GitHub checks are passing
• [ ] The correct base branch is being used, if not main

[CLAassistant]

All committers have signed the CLA.

[expressvpn-raihaan-m]

Hi Juliusz, thank you so much for your PR. We appreciate your help into upgrading our current use of DTLS1.2 to the new and improved DTLS1.3.

My main concern with this PR is that IIUC, it breaks backwards compatibility with DTLS1.2, as it uses the wolfDTLSv1_3_server_method instead of wolfDTLS_server_method. Unfortunately that is a non-starter for us. For us, we have millions of clients that only have DTLS1.2 support currently and a breaking change like that would leave all of these clients stranded.

Upgrading our servers to support DTLS1.2/1.3 and later clients to only support DTLS1.3 would allow us or any other users of this repo to upgrade their server infra first. Then later, release the client while still remaining compatible during the client rollout.

[expressvpn-pete-m]

@julek-wolfssl thanks for putting this together and really excited that we could soon support DTLS/1.3. As @expressvpn-raihaan-m mentions though, we do need to offer backwards support, but if we can find a way to address that, we'd be more than happy to accept this 😊

[julek-wolfssl]

Thanks for the replies @expressvpn-raihaan-m and @expressvpn-pete-m! wolfSSL does have API to allow for downgrading. DTLS 1.3 to 1.2 is actually non trivial because different fields make up the transcript hash! I'll try to put together a version that allows downgrading between 1.3 and 1.2.

[expressvpn-pete-m]

I think the big gotcha is likely to be that we need to do secure renegotiation 😊

[julek-wolfssl]

Once 1.2 is negotiated, you will be able to do secure renegotiation just as you do currently. With 1.3 this has been changed to key updates which is a streamlined way to update cipher material.

[julek-wolfssl]

I added the API calls to allow for downgrading the connection (for both client and server) to DTLS 1.2. It compiles but the tests fail because the API is called a different amount of times. I unfortunately don't have time to go through and correct the tests. This also means that I wasn't able to test this with lightway-laser.

[julek-wolfssl]

Hi @expressvpn-pete-m @expressvpn-raihaan-m , were you able to test the pull request in the current state?

[expressvpn-raihaan-m]

Hi @expressvpn-pete-m @expressvpn-raihaan-m , were you able to test the pukl request in the current state?

Hey @julek-wolfssl sorry for taking so long to get back to you. I've tested this with our internal tools and unfortunately its not backwards compatible in its current state it seems. I get a HE_ERR_INCORRECT_PROTOCOL_VERSION I'm unsure why right now as I've not dug deeper.

[julek-wolfssl]

I'm glad we were able to get the patch merged! Thank you for the bug reports.