Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tinydtls-dev] State of things, bugs and conformance

Hello Paul,

Very sorry for that - since we use our own TinyDTLS submodule we do not really always visit that
page. We are currently performing a lot of fuzzing on the NG code itself but any results on the DTLS
parts are of course welcome. We are doing a lot of work currently on adding features to the tinyDTLS
we have, but optimally we should merge efforts with upstream tinyDTLS as that will be best for both…
Not sure if any of the two teams have time to do the merge.

Was it you how posted something in Mars?

Again: sorry for being very slow on that repo.

Best regards,
— Joakim Eriksson, RISE

On 18 Jun 2019, at 10:18, Paul Brostean <pfgramer2005@xxxxxxxxx> wrote:

Hello again,

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.

Thanks, Paul.

On Monday, June 17, 2019, 8:56:57 PM GMT+2, Joakim Eriksson <ruben.joakim.eriksson@xxxxxxxxx> wrote:

Hi Paul, and Olaf,

We did a significant refactoring of TinyDTLS for Contiki-NG as we needed to
use it in a bit of a less common use-case. I will put some words / comments 

On 17 Jun 2019, at 19:10, Olaf Bergmann <bergmann@xxxxxxx> wrote:

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
( Our goal is to develop techniques for finding bugs in IoT
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:

tinydtls is an Eclipse Incubation project (under the hood of the Eclipse
IoT track). Its official repository lives at

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

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

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.

Only reason for change of affiliation is that we have had a merger of research institutes in
Sweden - SICS is now merged into RISE so I am no longer joakime@xxxxxxx but joakim.eriksson@xxxxx
But I will still respond if someone “calls” out ;-) - I agree that there are other OS:es with more
traction - but some of them do lack mesh IoT stack for 802.15.4 so if that is your target I’d say
Contiki is still king ;-) If you aim at BLE - it is not the case.

If there would be any interest in taking in the refactoring we did to enable more “standalone”
usage of TinyDTLS we might be able to upstream some of it. But that would require someone
in the TinyDTLS team to discuss the ideas and turns we took.

Best regards,
— Joakim Eriksson, RISE / SICS / NES

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 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!


tinydtls-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top