[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tinydtls-dev] State of things, bugs and conformance
|
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