TinyDTLS integration with gcoap - pokgak/RIOT GitHub Wiki

DTLS API is largely based on TLS, which is targeted for TCP connections. So it is harder to make it semantically similar to UDP.

Meeting 12.12.2018

  • sock_secure API for both TLS and DTLS is not needed in RIOT use cases. In an IoT environment, the users typically knows from start which underlying protocol to use.
  • sock_secure and tdsec uses connect as part of API to create session between client and server, which is confusing to API users because traditional socket has different meaning for connect
    • wolfSSL's create and destroy is better
  • Passing the created sock_udp like in tdsec is probably better because then the application still have access to the sock
Conclusion
  • 2 different APIs for TLS and DTLS
  • wolfSSL as reference for the API with approach in tdsec

Current status - 4.12.2018

work by wolfSSL team
  • PR 10308 - waiting for review
  • provides wrapper for basic operation (create/destroy/close context, session) sock_dtls API
work by rfuentess

Two parts API secure_sock and TLSMAN:

  • sock_secure (old: secure_sock): sits on top of sock and uses TLSMAN to abstracts which dtls implementation are used (tinydtls, wolfssl)
    • latest API update:
      • sock_secure should be integrated into sock as optional (like sock_async)
      • modifications to current modules (e.g. gcoap) should be minimum
    • PR #9450: working test with nanocoap, gcoap partially working.
  • TLSMAN: abstracts away the underlying SSL/TLS implementation so that it is transparent to the users

    with current (17.8.2018) form of sock_secure, it is hard to integrate with gcoap

    • gcoap runs its own event loop and handle timeout
work by kb2ma

tdsec, as a kind of 'simplest possible' sock wrapper for tinydtls to work with gcoap.

  • is a tinydlts-based adapter for sock
  • uses sock and dtls internally, hides it away from the user (application like gcoap)
generic sock

Summary

  • the current sock_secure and TLSMAN cannot easily be integrated into gcoap because it wants to handle all messages by itself (instead of letting gcoap uses its own event loop, handles messages by itself)
  • the event loop and listening in gcoap can be avoided if gcoap uses event to wait like stated in this comment. kb2ma said that test with async sock is being worked on.
  • tdsec is the most close to a working integration of tinydtls with gcoap (but specific to tinydtls and sock)
  • if sock is generic (which is still a WIP, in discussion), the underlying implementation (sock_udp, sock_tcp, sock_secure) should be interchangeable without affecting other modules (e.g. gcoap)

things to read on

  • sock_async
  • generic sock
  • synchronous handling in application
  • gcoap sock implementation - "gcoap sock take both the role of client/server"