Theodor Midtlien

We are not using the SSH package provided by the crypto library, so we are not affected by these vulnerabilities. This also requires us to upgrade the minimum go version...

Thanks for starting on this! I think this PR should be scoped to implement the HKDF functions: `HKDF-Expand-Label` and `Derive-Secret` as you have started on. This will be one part...

@philipch07, yes we should also export a HkdfExtract function, good catch.

I have made some changes to the draft to make better use of the standard crypto library and should be more in-line with the [TLS 1.3 implementation](https://cs.opensource.google/go/go/+/master:src/crypto/internal/fips140/tls13/tls13.go;drc=99b724f4542f4d9fb4a2ceacbbd2a6d9367dc0f6;bpv=0;bpt=1;l=20). I also think...

@JoeTurki, I agree that we should wait to merge this until we are closer to a WIP for DTLS 1.3. Unfortunately, this blocks much of the implementation, so we should...

This also includes [section 6.1 of RFC 9147](https://datatracker.ietf.org/doc/html/rfc9147#name-epoch-values-and-rekeying), which again references the entire [section 7 of RFC 8446](https://www.rfc-editor.org/rfc/rfc8446#section-7). The complete Key Schedule/Derivation functionality will be a larger effort that is...

@JoeTurki 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....

This PR is ready for review. 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...

Thanks for this draft! I have made some adjustments to your suggestion. I have taken inspiration from the TLS 1.3 implementation in the standard library where they [reuse TLS 1.2...

@philipch07 thanks for the feedback. Regarding naming, we could change it to something like `supported_groups_and_elliptic_curves`. I think the comment is enough, as it will be shown to a developer using...