How do you enable secure CoAP?

[beriberikix]

(resurfacing the question for Slack)

I'm trying to use coaps when interacting with my cloud server and the only examples are insecure CoAP. Part of the issue is configuring DTLS 1.2. @rlubos pointed us to the LwM2M code:

This is how DTLS client is configured in LWM2M:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/lwm2m/lwm2m_engine.c#L4320
And a similar example in echo_client:
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/sockets/echo_client/src/udp.c#L81

However, when we tried to able a similar configuration, the client sends DTLS 1.0 (which our server currently doesn't like.) More from Robert:

I faced similar issue with tinyDTLS server, and the conclusion was (backed by RFCs) that it's fine for the client to send version 1.0 at the record layer, and 1.2 at the client_hello, here's the comment I found with explanation:
https://github.com/obgm/libcoap/issues/160#issuecomment-381536186

Anyone have pointers on how to implement secure CoAP?

[rlubos]

Just to provide some more feedback, it's mbedTLS that hardcodes the DTLS version in the initial handshake to DTLS 1.0:
https://github.com/zephyrproject-rtos/mbedtls/blob/master/library/ssl_tls.c#L9305
So I'm not sure if it's even possible to use any different version w/o modifying the mbedTLS sources.

[beriberikix]

Ah! So is it technically a mbedTLS bug, albeit spec compliant, and should we file something there?

[rlubos]

Well, if it's spec compliant I wouldn't call it a bug, but reaching the mbedTLS community to get their insight on the issue sounds like a good idea.

[dtquang89]

Hi,

I am trying to use secure COAP and got an issue when compiling: undefined reference to otCoapSecureSetPsk'`. This function is declared in "coap_secure.h".

In prj.conf, I already added CONFIG_OPENTHREAD_COAPS=y.
But in coap_secure_api.cpp file, looks like I need to define MBEDTLS_KEY_EXCHANGE_PSK_ENABLED in order to activate this function. Can you please show me how to declared this config, I cannot find the correct configuration key?

Please feel free to let me know if you have any suggestions.

Best regards,
Quang

[rlubos]

Hi,

If you use Kconfig to configure mbed TLS (Zephyr default) you should enable CONFIG_MBEDTLS_KEY_EXCHANGE_PSK_ENABLED=y in your project file.

Otherwise, if you provide your own config file for mbed TLS, you should add #define MBEDTLS_KEY_EXCHANGE_PSK_ENABLED in there.

[dtquang89]

Thank you for the suggestion. It worked for me.

[boaks]

Maybe some late additional specification background information about the DTLS 1.0:

[RFC6347 - 4.2.1. Denial-of-Service Countermeasures](https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1)

The server_version field has the same syntax as in TLS. However, in
order to avoid the requirement to do version negotiation in the
initial handshake, DTLS 1.2 server implementations SHOULD use DTLS
version 1.0 regardless of the version of TLS that is expected to be
negotiated. DTLS 1.2 and 1.0 clients MUST use the version solely to
indicate packet formatting (which is the same in both DTLS 1.2 and
1.0) and not as part of version negotiation. In particular, DTLS 1.2
clients MUST NOT assume that because the server uses version 1.0 in
the HelloVerifyRequest that the server is not DTLS 1.2 or that it
will eventually negotiate DTLS 1.0 rather than DTLS 1.2.

The idea behind that seems to be to not negotiate the version until the peer's address is verified. Especially, don't send an alert as "deny version" to a peer without verifying its address first.

During a "redesign" of that part in Eclipse/Californium in summer 2020, I also did a small research later in 2020 as follow up of reported issues about that change.

Eclipse/Californium - HelloVerifyRequest

Results in November 2020:

Implementation	DTLS Version in CH and HVR
openssl 1.1.1	1.0
gnutls 3.5.18	1.0
mbedtls 2.24.0	1.2
wolfssl 4.5	1.2
tinydtls	1.0 and 1.2

I asked also the IETF/TLS mailing list but could not get an answer there.

Finally I decided to make Californium flexible at that, means: send the client the version back, which the client itself is using. That approach seems to be the one with the lowest troubles and works quite well since end of 2020.