Hello Benjamin,

I’ll try to address part of your questions:

• First, regarding delayed handshakes. In sockets_tls.c:

• if (net_context_get_type(ctx) == SOCK_STREAM) {
• /* Do the handshake for TLS, not DTLS. */

This had our scratching our heads for a while today because net_app DTLS seemed to handshake immediately. Why does ztls_connect_ctx delay handshake for DTLS?

A `connect` call for DTLS socket is optional (same as for UDP sockets) therefore we perform the handshake during initial send (for DTLS client). If you find it beneficial to initiate the handshake during the `connect` call as well for the DTLS, we can consider adding such functionality. Please file an github issue for that.

• The second question is regarding TLS HOSTNAME. I think I recall reading that this is required by default, but can be disabled. What's the proper way of doing this?

Yes, it is enforced by default due to security reasons. It can be disabled (though not recommended!) by explicitly setting `TLS_HOSTNAME` option to a NULL string.

• Third, has anyone successfully verified sockets and DTLS with a driver using the net_offload API? Some of the asserts and backtraces we've been observing while trying to get it to work today has been sort of... suspicious. Just wondering if anyone can verify that nothing has been broken.

I won’t be much help here as I’ve not used net_offload API. Keep in mind though that networking stack in Zephyr has undergone very large rework recently, so perhaps there is some issue that has not been identified yet.

Best regards,

Robert

Hi again,

• Good info re: HOSTNAME. Would keeping it enable require working DNS? We haven't had time to verify that DNS works. Indeed we know that it was broken under net_app so we haven't really bothered.

No, to my knowledge it is not bound to DNS in any way. This information is needed by mbedTLS to verify hostname bound to the certificate the server provides. We use it in samples where DNS is not enabled (see echo_client/server).

• Another thing that seemed slightly broken under net_app was re-initializing the DTLS handshake when we suspected a lost connection, do you know if this is still an issue?

This should not be an issue (unless anything got broken recently). If you suspect a lost connection, you can simply close the socket to free resources, and then create a new one.

Additionally, DTLS server utilizes mechanism available in mbedTLS to timeout DTLS connection – you can specify a timeout value after which DTLS connection is considered down, and DTLS resources are freed. In this case you do not need to close/reopen socket. The timeout value can be configured through Kconfig (and can be disabled as well this way). Just note, that this mechanism works only for DTLS server, not client.

Best regards,

Robert