@mattcaswell @t8m Please have a look.

CI failure looks relevant

CI failure looks relevant

Agreed. It was there with the first commit. I'll give it a look now.

Looks good. One minor comment and the CI failure to resolve.

Fixed the minor.
For the CI failure I am treating SCTP as broken for DTLSv1.3. I have it on my todo list.

There's a failure on the latest commit which I don't believe is relevant.

Out of curiosity: How is the SCTP auth export supposed to work? I see that the SSL_export_keying_material() gets called in tls_process_server_hello(). And that the former calls tls1_export_keying_material()/tls13_export_keying_material(). The tls13_export_keying_material() adds some sanitity checks and one of them namely ossl_statem_export_allowed() is failing.

As far as I understand this check should only pass after the FINISH message, so how is that supposed to work when it gets called from the tls_process_server_hello()?

Out of curiosity: How is the SCTP auth export supposed to work? I see that the SSL_export_keying_material() gets called in tls_process_server_hello(). And that the former calls tls1_export_keying_material()/tls13_export_keying_material(). The tls13_export_keying_material() adds some sanitity checks and one of them namely ossl_statem_export_allowed() is failing.

As far as I understand this check should only pass after the FINISH message, so how is that supposed to work when it gets called from the tls_process_server_hello()?

The current code only gets called from tls_process_server_hello in the event of s->hit being true (i.e. we are resuming). Obviously in the current code we are always talking about DTLSv1.2 or below so we only ever go into tls1_export_keying_material (tls13_export_keying_material is obviously currently only relevant in non-DTLS cases).

tls1_export_keying_material can be called prior to the finish and is only dependent on the client and server random values having been exchanged and there being a master key in the session. Since we are resuming that master key is already present even at this early stage. So everything all works out ok for SCTP.

It seems to me that SCTP is not yet well defined in the DTLSv1.3 case. There is a draft:

https://www.ietf.org/archive/id/draft-tuexen-tsvwg-rfc6083-bis-04.html

@tuexen might be able to comment further on its status.

I would suggest that we don't attempt to enable SCTP for DTLSv1.3 until an actual RFC exists for it.

I would suggest that we don't attempt to enable SCTP for DTLSv1.3 until an actual RFC exists for it.

Ah fair. I was looking at this from rfc6063:

This document is based on [RFC4347], and it is expected that DTLS/
SCTP as described in this document will work with future versions of
DTLS.

And hence didn't consider any updated RFC

I've noticed recently that sometimes ci checks are cancelled somewhat randomly. What's the reason for this? Is it new behaviour?

I've noticed recently that sometimes ci checks are cancelled somewhat randomly. What's the reason for this? Is it new behaviour?

Actually I'm not sure why this happens.

I've rebased and fixed two conflicts. Please reconfirm @mattcaswell.

I've noticed recently that sometimes ci checks are cancelled somewhat randomly. What's the reason for this? Is it new behaviour?

Actually I'm not sure why this happens.

IMO it is (was) some Github flakiness. It looks like it has been fixed.

This pull request is ready to merge