First of all, thanks to both for making clear the connection between the two versions.
And major thanks for the unexpectedly quick responses!
Since eclipse's tinydtls has a similar API to the TinyDTLS version we have thus far analyzed, it is very easy for us to include it in our setup for fuzzing.
I will suggest to my group we do so, and report any bugs discovered as issues to eclipse's tinydtls repository.
We will similarly, report issues discovered on the Contiki-NG version to the its repository.
My concern there is the seeming lack of activity.
I posted an issue a while back asking how the bugs should be reported but have yet to get an answer.
As for the problem I highlighted with regards to retransmissions, I am confident the issue is real.
What I cannot say for sure is whether the cost of fixing it is worth the benefits in terms of improved reliability.
I can imagine the ChangeCipherSpec message is a tricky message to handle, in that it's not a handshake message, yet has to be treated as such for the purpose of retransmission.
To restate in few words, the problem arises when the Finished sent by the client arrives before the ChangeCipherSpec (which it can, as it is part of the same flight).
Then, the TInyDTLS server will remove the association and the handshake will be lost.
This happens in both versions of TinyDTLS.
Thanks again for the clarifications.
Olaf, when you have time, could you look at the scenario I presented.
If you deem it to be a real 'practical' issue, I can add it as an issue to the repository.