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

[Paul Brostean <pfgramer2005@xxxxxxxxx>]

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 

inline.

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
(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.

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

_______________________________________________
tinydtls-dev mailing list
tinydtls-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/tinydtls-dev