DTLS 1.3 FSM architecture

[theodorsm]

Description

I have made a WIP DTLS 1.3 configuration and architecture.

As suggested by @JoTurk, it implementes a functional options pattern to provide flexibility in the future. A DTLS 1.3 configuration is created with NewConfigVersion13(c Config, opts ...OptionVersion13) (*Config, error) where an option/config can be implemented like this:

func WithOption13(f func(b bool)) OptionVersion13 {
	return func(c *Config) error {
		c.comeConfig = b
		return nil
	}
}
*/

The codebase for DTLS 1.2 and DTLS 1.3 splits off in conn.go with the new handshake13 function and the new handshakeFSM in handshaker_13.go (note that neither reflects DTLS 1.3 logic yet, just a copy/paste). I suggest we split off as much code as possible suffixed with _13 to keep the development of DTLS 1.3 separate from 1.2.

This PR contains a test of enabling DTLS 1.3 and verifies that an error is returned correctly, as we have not yet started to implement DTLS 1.3 flights.

I would appreciate some input from other maintainers on this! @JoTurk, @daenney, @Sean-Der.

Reference issue

Fixes #731

[JoTurk]

I'm just concerned that if we expose a public APIs, it'll be extremely difficult to change or remove it later, just my personal take about the dtls 1.3 suffix, maybe a sub package? what do you think?

[theodorsm]

@JoTurk thanks!

I agree that we should keep the API private until the DTLS 1.3 implementation is ready; we should only make it public as the last thing to do. If that is what you meant by it?

Regarding the sub-package or suffix: It depends. Using a sub-package I am afraid to loose access to some private fields in structs or functions that can be valuable for the implementation. Using a suffix, we can move fast without those problems, but it will be a bit messy file-wise (especially with flights). Will definitely have another look to see what's possible. I think a combination might be a good solution.

[JoTurk]

I agree that we should keep the API private until the DTLS 1.3 implementation is ready; we should only make it public as the last thing to do. If that is what you meant by it?

Yeah this will be a good call, private or sub package, but private will be better, I agree , for example: if we expose NewConfigVersion13 we'll not be able to remove it in the future :(

[codecov]

Codecov Report

❌ Patch coverage is 47.26027% with 77 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.72%. Comparing base (fd27a52) to head (2b9d0dd).

Files with missing lines	Patch %	Lines
flight_13.go	14.28%	36 Missing ⚠️
conn.go	64.40%	17 Missing and 4 partials ⚠️
handshaker_13.go	51.51%	16 Missing ⚠️
flighthandler_13.go	0.00%	4 Missing ⚠️

❌ Your patch check has failed because the patch coverage (47.26%) is below the target coverage (70.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #738      +/-   ##
==========================================
- Coverage   82.44%   81.72%   -0.73%     
==========================================
  Files         121      124       +3     
  Lines        6928     7049     +121     
==========================================
+ Hits         5712     5761      +49     
- Misses        805      874      +69     
- Partials      411      414       +3     

Flag	Coverage Δ
go	81.72% <47.26%> (-0.73%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[theodorsm]

The goal here is not to be complete, but to provide a best-effort skeleton with my current understanding of how the DTLS 1.3 implementation would look. It still contains some duplicate code in conn.go (the linter loves to complain about it), which shall be modified when we implement more of the DTLS 1.3 spec (such as the new record layer encoding #755 ).

I still think the _13 suffix is a good way of structuring to move on without large refactorings. This reduces the number of new public APIs (now private) we would need to expose when using a sub-package. I reduced the flight handlers files by grouping them into flighthandlers_client_13 and flighthandlers_server_13. We can always decide to make a sub-package later if we see it necessary.

[theodorsm]

The config is split to another PR #823

[theodorsm]

There are some TODOs here, but they are mainly regarding the new record demultiplexing. This is addressed in #793.

This PR is not supposed to be complete, but the changes are private so we can get it merged to unblock working on the DTLS 1.3 implementation further. It will affect #766