DTLS 1.3 MVP features

[theodorsm]

This issue aims to collect features needed for an MVP DTLS 1.3 implementation and serve as the starting point for a more rigorous implementation down the line (discussed in #188).

• Config API
• supported_version extension
• cookie extension
• signature_algorithms/cert extension update
• Mandatory-to-Implement cipher suites (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256).
• Mandatory-to-Implement signatures (rsa_pkcs1_sha256, rsa_pss_rsae_sha256 and ecdsa_secp256r1_sha256).
• key_share extension
• PSK extensions
• EncryptedExtensions
• ACK
• Record layer encoding update
• Encrypted sequence numbers
• Key derivation
• Finished message / Transcript Hash update
• Certificate/Request message update
• 1-RTT handshake flights
• HelloRetryRequest
• Post Handshake Messages

[philipch07]

I would love to help with each of these tasks, but I'm a bit new to this. Would you be able to provide some docs/links that would be handy so I can start helping? I should be free to begin this week; tomorrow I plan to work on pion/webrtc#3228 until webrtc is >80% (or maybe a little more).

[theodorsm]

@philipch07 awesome! The specifications are mostly documented in https://datatracker.ietf.org/doc/html/rfc9147 and https://datatracker.ietf.org/doc/html/rfc8446. I think the supported_version extension and HelloRetryRequest messages are the easiest to get going with.

Please create an issue if you start working on something, reference this issue, and keep the branch updated. This is so we don't end up working on the same thing ;)

I'm going to work on these features and DTLS 1.3 for some hours per week until the new year, then full-time in 2026.

[philipch07]

Thank you for the instructions! I can begin looking at this in depth today. I'll start with your recommendations.

With regards to moving to v1.3, is there a specific strategy you have in mind regarding keeping v1.2 intact? I just want to make sure we have the same idea for how to do this in an organized way.

[theodorsm]

I think the best way of keeping version 1.2 intact is by implementing the handshake logic and flights of version 1.3 separately in files suffixed with _13. I am working on adding the configuration flag for enabling DTLS 1.3 and a WIP architecture now. The marshaling/unmarshaling of extensions can be added without having this architecture in place, but implementing the logic would be blocked.

@philipch07 cool that you are working on the supported_versions. The HelloRetryRequest message is blocked by this extension, the key_share extension, and the architecture. We should wait to implement the HelloRetryRequest message and circle back to it together later.

I will take a look at the key_share extension after implementing the config flag and architecture for DTLS 1.3.

[philipch07]

Awesome, thank you! The _13 suffix sounds good to me. I'm looking forward to the config flag + architecture changes!

I'm still figuring out how Pion's DTLS v1.2 implementation handles extensions so it might take me a while to make any significant progress, but I'll ask questions as they come up within the respective issue so as to not clutter this one.

[philipch07]

Would you happen to have any other ideas for the next task I can help with @theodorsm? I just want to make sure that if I start on another task that it won't conflict/complicate your work.

No worries if you need more time to plan, and feel free to let me know how I can best help out!

[theodorsm]

@philipch07, sorry for the late reply.

I am still thinking about the order of the sub-tasks above, which will be the least blocking, but it's a lot of planning. However, I think I will continue to work on the handshake and flight arch to aid this process.

I have not yet started on the key_share extension, so maybe that could be a good thing to look at after #737. A more pressing issue that should be completed before this is #739. It is slightly related, but also impactful for DTLS 1.2.

[philipch07]

No worries, and thanks for getting back to me!

I am still thinking about the order of the sub-tasks above, which will be the least blocking, but it's a lot of planning. However, I think I will continue to work on the handshake and flight arch to aid this process.

Sounds good to me. Thank you for taking the time to carefully plan each step; it really is quite a large project and I don't mean to rush you at all.

I have not yet started on the key_share extension, so maybe that could be a good thing to look at after #737.

Regarding #737, I don't mind leaving it as a draft for a while until the scaffolding/architecture is completed since it would probably be easier for reviewers/auditors to have a clean commit history. As for the key_share extension, I can maybe look into that soon (unfortunately I don't have a specific timeline). I'll make a PR/sub-issue for it if I start on it to make sure we don't accidentally overlap.