We have been testing TinyDTLS using various techniques (afl fuzzing, state fuzzing). The version we use is:
I was wondering if you could tell me about the relation between this version and the version in the eclipse repositories:
Anyway, on the version we tested we found several bugs via fuzzing which may or may not be reproducible in the eclipse version. We can replicate these tests also on the eclipse version, or do systematic fuzzing of it, but it would be encouraging to know that any bugs reported would eventually be fixed. This would be very useful for us in our research. Note, some of the bugs were really serious. For example, records having certain configurations could crash the TinyDTLS server
Using state fuzzing we were able to generate models of TinyDTLS. Analyzing the results we found that TinyDTLS might not handle out-of-order messages properly, but I wanted to talk to you about it before drawing conclusions. Note that this later problem affects both versions of TinyDTLS.
We notice that in file dtls.c:
'decrypt_verify' returns -1 if no cipher has been negotiated for the record epoch as well as if there is error in decryption
'dtls_handle_message' calls 'decrypt_verify', if method returns -1 it removes the association and generates Alert(DecryptError).
The problem with this approach is that in a handshake between a client and a server, the server could receive the last flight of messages sent by the client in the following disorderly way:
PskClientKeyExchange(epoch=0)
Finished(epoch=1)
ChangeCipherSpec(epoch=0)
When processing the Finished message, the TinyDTLS server removes the association due to a bad epoch (bad as in, no cipher was negotiated for it). From that point onward, association is lost and a new handshake would have to be restarted.
I was wondering if this behavior did not represent a problem, particularly over unreliable networks? My impression is that it breaks the retramission mechanism suggested in:
I tried this scenario on other DTLS implementations such as OpenSSL, MbedTLS, and GnuTLS and they all could still finish the handshake, assuming the last Finished message was retransmitted. That seems to be the desired behavior.
So basically, what I am asking is:
1. is there any relation between the two repos, are there plans for the repos to be kept in sync
2. is this a good environment to post bugs found via fuzzing, if so, we are more than willing to do systematic fuzzing on the eclipse variant of TinyDTLS
3. is the reordering scenario problematic? I understand that this could have been a design decision meant to simplify the implementation.
I attached the a capture showcasing the reordering scenario. The two encrypted messages are Finished messages.
Thanks, Paul.
