[riot-notifications] [RIOT-OS/RIOT] [WIP] sock_secure module (#9450)
notifications at github.com
Fri Feb 1 15:06:20 CET 2019
As he mentioned in #10897 @pokgak, @MichelRottleuthner, @haukepetersen, myself and several others revisited the proposed (D)TLS APIs for a project related work and we came to the conclusion that this API ‑ as it is currently proposed ‑ is too involved for the embedded context. Furthermore, it directly contradicts the requirement that a DTLS API should be transparent to the underlying transport layer API [ref missing (someone mentioned that this is discussed in somewhere)], which also makes sense from a usage point of view when implementing a library such as gcoap which is supposed to support both secure (coaps://) and unsecure (coap://) communication (as discussed by @kb2ma).
We would rather propose to go for the more "thin wrapper" approach and have a `sock_dtls` and `sock_tls` first on which basis a unified API (like this one) can be build on top. However, to be perfectly honest, we don't see the requirement for that (yet).
@pokgak proposed a solution for `sock_dtls` based on the proposals by @kb2ma ([tdsec.h]) and @danielinux ([sock_tls.h]) in #10897. We decided to go for yet another approach, since those two both are to dependent on the underlying library (for tdsec.h it's mostly naming and parameters and sock_tls.h didn't even provide a wrapper around wolfSSL's send/recv functions last time we looked at it in detail in late December). The solution in #10897 is more "in the spirit of sock" as it plugs directly into the existing `sock_udp` solution and the decision of what DTLS implementation is used is made at compile-time (as for `sock_udp` e.g. with the UDP implementation respectively).
While this initial work was valuable to kickstart the discussion around a unified API for DTLS we want converge on a viable solution most people can agree with, so I hope that it is okay, that we close this PR for now and revisit your proposal once a requirement for a unified transport layer security API arises.
Regarding the `async_sock` discussion: That also needs some work, which I promise continue very soon. This in mind, the asynchronous behavior for that should be introduced independent from @pokgak's proposal, either in #8149 itself or a follow-up to both.
Feel free to reopen if you disagree.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications