Error in description of resource DTLS/TLS Ciphersuite of Security Object ?

[sbernard31]

I'm not sure but there is maybe an error in description of resource DTLS/TLS Ciphersuite (id:16) of Security Object (Id:0).

The specification LWM2M-v1.2.1@core§Table: E.1-2 LwM2M Object: LWM2M Security Resource definitions says :

When this resource is present it instructs the TLS/DTLS client to propose the indicated ciphersuite(s) in the ClientHello of the handshake. A ciphersuite is indicated as a 32-bit integer value. The IANA TLS ciphersuite registry is maintained at https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml. As an example, the TLS_PSK_WITH_AES_128_CCM_8 ciphersuite is represented with the following string "0xC0,0xA8". To form an integer value the two values are concatenated. In this example, the value is 0xc0a8 or 49320.

I understand that ciphersuite are identified by 2 byte (e.g. 0xC0,0xA8"), so "A ciphersuite is indicated as a 32-bit integer value." sounds strange to me ?
Should it be "16-bit unsigned integer value" instead ? or maybe I misunderstood something ?

[jvermillard]

For completeness would be helpful to specify that the representation is Big Endian, which you deduce from the example but not clearly stated.

[mkgillmore]

@sbernard31 has this been an interoperability issue?

[sbernard31]

AFAIK, nobody report interoperability issue, it think this is more a wording issue.

I understand that :

• A cipher suite ID is 2 byte following IANA
• the "DTLS/TLS Ciphersuite" resource is an unsigned integer.

So talking about 32-bit integer value seems a bit confusing to me.

• 32 bit is 4 bytes so doesn't match with IANA
• we talk about integer where LWM2M resource is unsigned integer.

I feel that "16-bit unsigned integer value" will be less confusing.

As said @jvermillard, clarifying endianess could also simplify LWM2M specification reader life (so they to don't need to guess that from the example)