]> Ericsson AB

john.mattsson@ericsson.com

Ericsson AB

francesca.palombini@ericsson.com

INRIA

malisa.vucinic@inria.fr

LWIG Working Group This document analyzes and compares the sizes of key exchange flights and the per-packet message size overheads when using different security protocols to secure CoAP. The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, EDHOC, OSCORE, and Group OSCORE. The DTLS and TLS record layers are analyzed with and without 6LoWPAN-GHC compression. DTLS is analyzed with and without Connection ID.

This document analyzes and compares the sizes of key exchange flights and the per-packet message size overheads when using different security protocols to secure CoAP over UPD and TCP . The analyzed security protocols are DTLS 1.2 , DTLS 1.3 , TLS 1.2 , TLS 1.3 , EDHOC , OSCORE , and Group OSCORE . The DTLS and TLS record layers are analyzed with and without 6LoWPAN-GHC compression. DTLS is anlyzed with and without Connection ID . Readers are expected to be familiar with some of the terms described in RFC 7925 , such as ICV. compares the overhead of key exchange, while covers the overhead for protection of application data.

This section analyzes and compares the sizes of key exchange flights for different protocols. To enable a fair comparison between protocols, the following assumptions are made: All the overhead calculations in this section use AES-CCM with a tag length of 8 bytes (e.g. AES_128_CCM_8 or AES-CCM-16-64-128). A minimum number of algorithms and cipher suites is offered. The algorithm used/offered are Curve25519, ECDSA with P-256, AES-CCM_8, SHA-256. The length of key identifiers are 1 byte. The length of connection identifiers are 1 byte. DTLS RPK makes use of point compression, which saves 32 bytes. DTLS handshake message fragmentation is not considered. Only the DTLS mandatory extensions are considered, except for Connection ID. gives a short summary of the message overhead based on different parameters and some assumptions. The following sections detail the assumptions and the calculations.

The DTLS overhead is dependent on the parameter Connection ID. The following overheads apply for all Connection IDs of the same length, when Connection ID is used. The EDHOC overhead is dependent on the key identifiers included. The following overheads apply for Sender IDs of the same length. All the overhead are dependent on the tag length. The following overheads apply for tags of the same length. compares the message sizes of EDHOC with the DTLS 1.3 and TLS 1.3 handshakes with connection ID.

compares of message sizes of DTLS 1.3 and TLS 1.3 handshakes without connection ID.

The details of the message size calculations are given in the following sections.

This section gives an estimate of the message sizes of DTLS 1.3 with different authentication methods. Note that the examples in this section are not test vectors, the cryptographic parts are just replaced with byte strings of the same length, while other fixed length fields are replace with arbitrary strings or omitted, in which case their length is indicated. Values that are not arbitrary are given in hexadecimal.

In this section, a Connection ID of 1 byte is used.

DTLS 1.3 RPK + ECDHE flight_1 gives 150 bytes of overhead.

DTLS 1.3 RPK + ECDHE flight_2 gives 373 bytes of overhead.

DTLS 1.3 RPK + ECDHE flight_2 gives 213 bytes of overhead.

The differences in overhead compared to are: The following is added:

The following is removed:

In total:

DTLS 1.3 PSK + ECDHE flight_1 gives 184 bytes of overhead.

The differences in overhead compared to are: The following is added:

The following is removed:

In total:

DTLS 1.3 PSK + ECDHE flight_2 gives 190 bytes of overhead.

The differences in overhead compared to are: The following is removed:

In total:

DTLS 1.3 PSK + ECDHE flight_3 gives 57 bytes of overhead.

The differences in overhead compared to are: The following is removed:

In total:

DTLS 1.3 PSK flight_1 gives 134 bytes of overhead.

The differences in overhead compared to are: The following is removed:

In total:

DTLS 1.3 PSK flight_2 gives 150 bytes of overhead.

There are no differences in overhead compared to . DTLS 1.3 PSK flight_3 gives 57 bytes of overhead.

In this section, we consider the effect of on the message size overhead. Cached information together with server X.509 can be used to move bytes from flight #2 to flight #1 (cached RPK increases the number of bytes compared to cached X.509). The differences compared to are the following. For the flight #1, the following is added:

And the following is removed:

Giving a total of:

For the flight #2, the following is added:

And the following is removed:

32 bytes) ]]>

Giving a total of:

A summary of the calculation is given in .

To enable resumption, a 4th flight (New Session Ticket) is added to the PSK handshake.

The initial handshake when resumption is enabled is just a PSK handshake with 134 + 150 + 57 + 42 = 383 bytes.

Without a Connection ID the DTLS 1.3 flight sizes changes as follows.

TODO

In this section, the message sizes are calculated for TLS 1.3. The major changes compared to DTLS 1.3 are that the record header is smaller, the handshake headers is smaller, and that Connection ID is not supported. Recently, additional work has taken shape with the goal to further reduce overhead for TLS 1.3 (see ). TLS Assumptions: Minimum number of algorithms and cipher suites offered Curve25519, ECDSA with P-256, AES-CCM_8, SHA-256 Length of key identifiers: 1 bytes TLS RPK with point compression (saves 32 bytes) Only mandatory TLS extensions For the PSK calculations, was a useful resource, while for RPK calculations we followed the work of .

TLS 1.3 RPK + ECDHE flight_1 gives 129 bytes of overhead.

TLS 1.3 RPK + ECDHE flight_2 gives 322 bytes of overhead.

TLS 1.3 RPK + ECDHE flight_3 gives 194 bytes of overhead.

The differences in overhead compared to are: The following is added:

The following is removed:

In total:

TLS 1.3 PSK + ECDHE flight_1 gives 166 bytes of overhead.

The differences in overhead compared to are: The following is added:

The following is removed:

In total:

TLS 1.3 PSK + ECDHE flight_2 gives 157 bytes of overhead.

The differences in overhead compared to are: The following is removed:

In total:

TLS 1.3 PSK + ECDHE flight_3 gives 50 bytes of overhead.

The differences in overhead compared to are: The following is removed:

In total:

TLS 1.3 PSK flight_1 gives 116 bytes of overhead.

The differences in overhead compared to are: The following is removed:

In total:

TLS 1.3 PSK flight_2 gives 117 bytes of overhead.

There are no differences in overhead compared to . TLS 1.3 PSK flight_3 gives 57 bytes of overhead.

This section gives an estimate of the message sizes of EDHOC with authenticated with static Diffie-Hellman keys. All examples are given in CBOR diagnostic notation and hexadecimal, and are based on the test vectors in Appendix B.2 of .

The typical message sizes for the previous example and for an example of EDHOC authenticated with signature keys and X.509 certificates based on Appendix B.1 of are summarized in .

To do a fair comparison, one has to choose a specific deployment and look at the topology, the whole protocol stack, frame sizes (e.g. 51 or 128 bytes), how and where in the protocol stack fragmentation is done, and the expected packet loss. Note that the number of bytes in each frame that is available for the key exchange protocol may depend on the underlying protocol layers as well as on the number of hops in multi-hop networks. The packet loss may depend on how many other devices are transmitting at the same time, and may increase during network formation. The total overhead will be larger due to mechanisms for fragmentation, retransmission, and packet ordering. The overhead of fragmentation is roughly proportional to the number of fragments, while the expected overhead due to retransmission in noisy environments is a superlinear function of the flight sizes.

To enable comparison, all the overhead calculations in this section use AES-CCM with a tag length of 8 bytes (e.g. AES_128_CCM_8 or AES-CCM-16-64), a plaintext of 6 bytes, and the sequence number ‘05’. This follows the example in , Figure 16. Note that the compressed overhead calculations for DLTS 1.2, DTLS 1.3, TLS 1.2 and TLS 1.3 are dependent on the parameters epoch, sequence number, and length, and all the overhead calculations are dependent on the parameter Connection ID when used. Note that the OSCORE overhead calculations are dependent on the CoAP option numbers, as well as the length of the OSCORE parameters Sender ID and Sequence Number. The following calculations are only examples. gives a short summary of the message overhead based on different parameters and some assumptions. The following sections detail the assumptions and the calculations.

The DTLS overhead is dependent on the parameter Connection ID. The following overheads apply for all Connection IDs with the same length. The compression overhead (GHC) is dependent on the parameters epoch, sequence number, Connection ID, and length (where applicable). The following overheads should be representative for sequence numbers and Connection IDs with the same length. The OSCORE overhead is dependent on the included CoAP Option numbers as well as the length of the OSCORE parameters Sender ID and sequence number. The following overheads apply for all sequence numbers and Sender IDs with the same length.

This section analyzes the overhead of DTLS 1.2 . The nonce follow the strict profiling given in . This example is taken directly from , Figure 16.

DTLS 1.2 gives 29 bytes overhead.

This section analyzes the overhead of DTLS 1.2 when compressed with 6LoWPAN-GHC . The compression was done with . Note that the sequence number ‘01’ used in , Figure 15 gives an exceptionally small overhead that is not representative. Note that this header compression is not available when DTLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC.

When compressed with 6LoWPAN-GHC, DTLS 1.2 with the above parameters (epoch, sequence number, length) gives 16 bytes overhead.

This section analyzes the overhead of DTLS 1.2 with Connection ID . The overhead calculations in this section uses Connection ID = ‘42’. DTLS recored layer with a Connection ID = ‘’ (the empty string) is equal to DTLS without Connection ID.

DTLS 1.2 with Connection ID gives 30 bytes overhead.

This section analyzes the overhead of DTLS 1.2 with Connection ID when compressed with 6LoWPAN-GHC . Note that the sequence number ‘01’ used in , Figure 15 gives an exceptionally small overhead that is not representative. Note that this header compression is not available when DTLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC.

When compressed with 6LoWPAN-GHC, DTLS 1.2 with the above parameters (epoch, sequence number, Connection ID, length) gives 17 bytes overhead.

This section analyzes the overhead of DTLS 1.3 . The changes compared to DTLS 1.2 are: omission of version number, merging of epoch into the first byte containing signalling bits, optional omission of length, reduction of sequence number into a 1 or 2-bytes field. Only the minimal header format for DTLS 1.3 is analyzed (see Figure 4 of ). The minimal header formal omit the length field and only a 1-byte field is used to carry the 8 low order bits of the sequence number

DTLS 1.3 gives 11 bytes overhead.

This section analyzes the overhead of DTLS 1.3 when compressed with 6LoWPAN-GHC . Note that this header compression is not available when DTLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC.

When compressed with 6LoWPAN-GHC, DTLS 1.3 with the above parameters (epoch, sequence number, no length) gives 12 bytes overhead.

This section analyzes the overhead of DTLS 1.3 with Connection ID . In this example, the length field is omitted, and the 1-byte field is used for the sequence number. The minimal DTLSCiphertext structure is used (see Figure 4 of ), with the addition of the Connection ID field.

DTLS 1.3 with Connection ID gives 12 bytes overhead.

This section analyzes the overhead of DTLS 1.3 with Connection ID when compressed with 6LoWPAN-GHC . Note that this header compression is not available when DTLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC.

When compressed with 6LoWPAN-GHC, DTLS 1.3 with the above parameters (epoch, sequence number, Connection ID, no length) gives 13 bytes overhead.

This section analyzes the overhead of TLS 1.2 . The changes compared to DTLS 1.2 is that the TLS 1.2 record layer does not have epoch and sequence number, and that the version is different.

TLS 1.2 gives 21 bytes overhead.

This section analyzes the overhead of TLS 1.2 when compressed with 6LoWPAN-GHC . Note that this header compression is not available when TLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC.

When compressed with 6LoWPAN-GHC, TLS 1.2 with the above parameters (epoch, sequence number, length) gives 17 bytes overhead.

This section analyzes the overhead of TLS 1.3 . The change compared to TLS 1.2 is that the TLS 1.3 record layer uses a different version.

TLS 1.3 gives 14 bytes overhead.

This section analyzes the overhead of TLS 1.3 when compressed with 6LoWPAN-GHC . Note that this header compression is not available when TLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC.

When compressed with 6LoWPAN-GHC, TLS 1.3 with the above parameters (epoch, sequence number, length) gives 15 bytes overhead.

This section analyzes the overhead of OSCORE . The below calculation Option Delta = ‘9’, Sender ID = ‘’ (empty string), and Sequence Number = ‘05’, and is only an example. Note that Sender ID = ‘’ (empty string) can only be used by one client per server.

The below calculation Option Delta = ‘9’, Sender ID = ‘42’, and Sequence Number = ‘05’, and is only an example.

The below calculation uses Option Delta = ‘9’.

OSCORE with the above parameters gives 13-14 bytes overhead for requests and 11 bytes overhead for responses. Unlike DTLS and TLS, OSCORE has much smaller overhead for responses than requests.

This section analyzes the overhead of Group OSCORE . TODO

DTLS 1.2 has quite a large overhead as it uses an explicit sequence number and an explicit nonce. TLS 1.2 has significantly less (but not small) overhead. TLS 1.3 has quite a small overhead. OSCORE and DTLS 1.3 (using the minimal structure) format have very small overhead. The Generic Header Compression (6LoWPAN-GHC) can in addition to DTLS 1.2 handle TLS 1.2, and DTLS 1.2 with Connection ID. The Generic Header Compression (6LoWPAN-GHC) works very well for Connection ID and the overhead seems to increase exactly with the length of the Connection ID (which is optimal). The compression of TLS 1.2 is not as good as the compression of DTLS 1.2 (as the static dictionary only contains the DTLS 1.2 version number). Similar compression levels as for DTLS could be achieved also for TLS 1.2, but this would require different static dictionaries. For TLS 1.3 and DTLS 1.3, GHC increases the overhead. The 6LoWPAN-GHC header compression is not available when (D)TLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC. New security protocols like OSCORE, TLS 1.3, and DTLS 1.3 have much lower overhead than DTLS 1.2 and TLS 1.2. The overhead is even smaller than DTLS 1.2 and TLS 1.2 over 6LoWPAN with compression, and therefore the small overhead is achieved even on deployments without 6LoWPAN or 6LoWPAN without compression. OSCORE is lightweight because it makes use of CoAP, CBOR, and COSE, which were designed to have as low overhead as possible. Note that the compared protocols have slightly different use cases. TLS and DTLS are designed for the transport layer and are terminated in CoAP proxies. OSCORE is designed for the application layer and protects information end-to-end between the CoAP client and the CoAP server. Group OSCORE is designed for group communication and protects information between a CoAP client and any number of CoAP servers.

This document is purely informational.

This document has no actions for IANA.

&I-D.ietf-core-oscore-groupcomm; &I-D.ietf-tls-dtls13; &I-D.ietf-tls-dtls-connection-id; &I-D.ietf-lake-edhoc; &I-D.rescorla-tls-ctls; &RFC5246; &RFC6347; &RFC7400; &RFC7252; &RFC7925; &RFC8323; &RFC8446; &RFC8613; &RFC7924;

The authors want to thank Ari Keränen, Carsten Bormann, Göran Selander, and Hannes Tschofenig for comments and suggestions on previous versions of the draft. All 6LoWPAN-GHC compression was done with .