Re: [tinydtls-dev] State of things, bugs and conformance

[Olaf Bergmann <bergmann@xxxxxxx>]

Hi Paul,

Thank you for reaching out to the tinydtls community. I will try to
answer your questions below:

Paul Brostean <pfgramer2005@xxxxxxxxx> writes:

> My name is Paul Fiterau. I am part of the aSSisT research group
> (https://assist-project.github.io/). Our goal is to develop techniques for finding bugs in IoT
> software.
> We have been testing TinyDTLS using various techniques (afl fuzzing,  state fuzzing). The
> version we use is:
> https://github.com/contiki-ng/tinydtls
>
> I was wondering if you could tell me about the relation between this version and the version
> in the eclipse repositories:
> https://github.com/eclipse/tinydtls

tinydtls is an Eclipse Incubation project (under the hood of the Eclipse
IoT track). Its official repository lives at https://github.com/eclipse/tinydtls

I am currently not aware of the status the tinydtls version that is used
in contiki-ng has.

> any bugs reported would eventually be fixed.

This is the intention. (There is some backlog, though, but the community
has also become a bit more active after the repository has been moved to
GH.)

> could crash the TinyDTLS server

Some implementation decisions indeed have been made to simplify the code
but anything that could crash the server must be fixed.

> 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

I am not sure. I did not get much feedback from Contiki folks after the
person who did the fork has changed hist affiliation. Currently, other
embedded operating systems seem to have more traction.

> 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

Indeed. Also, opening issues in the official GH repo at
https://github.com/eclipse/tinydtls is appreciated.

> 3. is the reordering scenario problematic? I understand that this could have been a design
> decision meant to simplify the implementation. 

I need to look at it in more detail but from your description it seems
to be unintended behavior.

> I attached the a capture showcasing the reordering scenario. The two
> encrypted messages are Finished messages.

Thank you!

Grüße
Olaf