Align PSK limits of example client and tinydtls binding.

[boaks]

libcoap: v4.3.0-rc4 (tinydtls binding):

• the definition MAX_USER in coap-client.c limits the identity to 128 bytes
• for tinydtls, the default of DTLS_PSK_MAX_CLIENT_IDENTITY_LEN is set to 32 bytes in crypto.h.

I would prefer consistent lengths, e.g. by overwriting the default DTLS_PSK_MAX_CLIENT_IDENTITY_LEN using a definition in the makefile.

[mrdeep1]

This can be easily be done.

However, this raises other questions and highlights potential issues.

There needs to be consistency for keys and hints as well. I think keys consistency for TinyDTLS could be a challenge as it is limited to 16.

The underlying (D)TLS library requests the identity, key and hint as appropriate, but indicate a maximum size. If the maximum size is not sufficient, the code currently silently returns 0 as the length of the returned entity. What should happen to an entity if the (D)TLS library storage space is not sufficient?

[boaks]

There needs to be consistency for keys and hints as well.

Indeed.

I think keys consistency for TinyDTLS could be a challenge as it is limited to 16.

If I remember that well, this is more a common misinterpretation, which made it into tinydtls. It was an assumption that using aes128 causes the the PSK secret to be limited to 16 bytes as well. See tinydtls, crypto.h

#define DTLS_KEY_LENGTH        16 /* AES-128 */

/* This is the maximal supported length of the pre-shared key. */
#define DTLS_PSK_MAX_KEY_LEN DTLS_KEY_LENGTH

The AES keys are the output of PRF and there length is not related to the length of the secret. RFC4279 defines

Note 1: All the ciphersuites in this document share the same
general structure for the premaster secret, namely,

     struct {
         opaque other_secret<0..2^16-1>;
         opaque psk<0..2^16-1>;
     };

as input of PRF for the premaster-secret, which indicates much larger possible secrets.

FMPOV, a definition in tinydtls guarded by #ifndeffor DTLS_PSK_MAX_KEY_LEN would be a start to overcome this. On the other side, 16 bytes are anyway secure enough, considering, that the secret is too often not stored in a HSM.