<p>As he mentioned in <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="404423351" data-permission-text="Issue title is private" data-url="https://github.com/RIOT-OS/RIOT/issues/10897" data-hovercard-type="issue" data-hovercard-url="/RIOT-OS/RIOT/issues/10897/hovercard" href="https://github.com/RIOT-OS/RIOT/issues/10897">#10897</a> <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=20373062" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/pokgak">@pokgak</a>, <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=20105554" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/MichelRottleuthner">@MichelRottleuthner</a>, <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=620834" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/haukepetersen">@haukepetersen</a>, 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 <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=2944058" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/kb2ma">@kb2ma</a>).</p>
<p>We would rather propose to go for the more "thin wrapper" approach and have a <code>sock_dtls</code> and <code>sock_tls</code> 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).</p>
<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=20373062" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/pokgak">@pokgak</a> proposed a solution for <code>sock_dtls</code> based on the proposals by <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=2944058" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/kb2ma">@kb2ma</a> (<a href="https://github.com/kb2ma/RIOT/blob/7e7d4b08dfece14ba96f9ded554d3064e0093203/sys/include/net/sock/tdsec.h">tdsec.h</a>) and <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=1027688" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/danielinux">@danielinux</a> (<a href="https://github.com/RIOT-OS/RIOT/blob/9b9ba1d0297c0fecb81f079e5a45230a047edc84/pkg/wolfssl/sock_tls/sock_tls.h">sock_tls.h</a>) in <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="404423351" data-permission-text="Issue title is private" data-url="https://github.com/RIOT-OS/RIOT/issues/10897" data-hovercard-type="issue" data-hovercard-url="/RIOT-OS/RIOT/issues/10897/hovercard" href="https://github.com/RIOT-OS/RIOT/issues/10897">#10897</a>.  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 <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="404423351" data-permission-text="Issue title is private" data-url="https://github.com/RIOT-OS/RIOT/issues/10897" data-hovercard-type="issue" data-hovercard-url="/RIOT-OS/RIOT/issues/10897/hovercard" href="https://github.com/RIOT-OS/RIOT/issues/10897">#10897</a> is more "in the spirit of sock" as it plugs directly into the existing <code>sock_udp</code> solution and the decision of what DTLS implementation is used is made at compile-time (as for <code>sock_udp</code> e.g. with the UDP implementation respectively).</p>
<p>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.</p>
<p>Regarding the <code>async_sock</code> 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 <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=20373062" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/pokgak">@pokgak</a>'s proposal, either in <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="277033187" data-permission-text="Issue title is private" data-url="https://github.com/RIOT-OS/RIOT/issues/8149" data-hovercard-type="pull_request" data-hovercard-url="/RIOT-OS/RIOT/pull/8149/hovercard" href="https://github.com/RIOT-OS/RIOT/pull/8149">#8149</a> itself or a follow-up to both.</p>
<p>Feel free to reopen if you disagree.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/RIOT-OS/RIOT/pull/9450#issuecomment-459733076">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AEn7YJ-VSmzybM98ZOKBYSZXcs2id7boks5vJEncgaJpZM4U7PBW">mute the thread</a>.<img src="https://github.com/notifications/beacon/AEn7YCaUFEN7xCRnoDZHS5meOqYQanJ6ks5vJEncgaJpZM4U7PBW.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/RIOT-OS/RIOT","title":"RIOT-OS/RIOT","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/RIOT-OS/RIOT"}},"updates":{"snippets":[{"icon":"PERSON","message":"@miri64 in #9450: 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).\r\n\r\nWe 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).\r\n\r\n@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).\r\n\r\nWhile 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.\r\n\r\nRegarding 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.\r\n\r\nFeel free to reopen if you disagree.\r\n\r\n[tdsec.h]: https://github.com/kb2ma/RIOT/blob/7e7d4b08dfece14ba96f9ded554d3064e0093203/sys/include/net/sock/tdsec.h\r\n[sock_tls.h]: https://github.com/RIOT-OS/RIOT/blob/9b9ba1d0297c0fecb81f079e5a45230a047edc84/pkg/wolfssl/sock_tls/sock_tls.h"}],"action":{"name":"View Pull Request","url":"https://github.com/RIOT-OS/RIOT/pull/9450#issuecomment-459733076"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/RIOT-OS/RIOT/pull/9450#issuecomment-459733076",
"url": "https://github.com/RIOT-OS/RIOT/pull/9450#issuecomment-459733076",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>