]> Ericsson

john.mattsson@ericsson.com

Ericsson

francesca.palombini@ericsson.com

INRIA

malisa.vucinic@inria.fr

IOTOPS 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. Small message sizes are very important for reducing energy consumption, latency, and time to completion in constrained radio network such as Low-Power Wide Area Networks (LPWANs). The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, cTLS, 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. About This Document Status information for this document may be found at . Discussion of this document takes place on the IOT Operations (iotops) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Small message sizes are very important for reducing energy consumption, latency, and time to completion in constrained radio network such as Low-Power Personal Area Networks (LPPANs) and Low-Power Wide Area Networks (LPWANs). Constrained radio networks are not only characterized by very small frame sizes on the order of tens of bytes transmitted a few times per day at ultra-low speeds, but also by high latency and severe duty cycles constraints. Some constrained radio networks are also multi-hop, where the already small frame sizes are additionally reduced for each additional hop. Too large payload sizes can easily lead to unacceptable completion times due to fragmentation into a large number of frames and long waiting times between sending each frame (or resending frames, in the case of transmission errors). In constrained radio networks, the processing energy costs are typically almost negligible compared to the energy costs for radio and the energy costs for sensor measurement. Keeping the number of bytes or frames low is also essential for low latency and time to completion as well as efficient use of spectrum to support a large number of devices. For an overview of LPWANs and their limitations, see and . To reduce overhead, processing, and energy consumption in constrained radio networks, IETF has created several working groups and technologies for constrained networks, e.g., (here technologies in parenthesis when the name is different from the working group): 6lo, 6LoWPAN, 6TiSCH, ACE, CBOR, CoRE (CoAP, OSCORE, Group OSCORE), COSE (COSE, C509), LAKE (EDHOC), LPWAN, SCHC, ROLL (RPL), and TLS (DTLS, cTLS). Compact formats and protocol have also been suggested as a way to decrease the energy consumption of Internet Applications and Systems in general . This document analyzes and compares the sizes of Authenticated Key Exchange (AKE) 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 , cTLS , EDHOC , OSCORE , and Group OSCORE . An AKE and a protocol for the protection of application data serve distinct purposes. An AKE is responsible for establishing secure communication channels between parties and negotiating cryptographic keys used for authenticated encryption. AKE protocols typically involve a series of messages exchanged between communicating parties to authenticate each other's identities and derive shared secret keys. TLS, DTLS, and cTLS handshakes as well as EDHOC are examples of AKEs. Protocols for protection of application data are responsible for encrypting and authenticating application-layer data to ensure its confidentiality, integrity, and replay protection during transmission. The TLS and DTLS record layers, OSCORE, and Group OSCORE are examples of protocols for protection of application data. compares the overhead of mutually authenticated key exchange protocols, while covers the overhead of protocols for protection of application data. The protocols are analyzed with different algorithms and options. The DTLS and TLS record layers are analyzed with and without 6LoWPAN-GHC compression . DTLS is analyzed with and without Connection ID . Readers are expected to be familiar with some of the terms described in RFC 7925 , such as Integrity Check Value (ICV). Readers of this document also might be interested in the following documents: , , , and explain every byte in example TLS 1.2, TLS 1.3, DTLS 1.3, and EDHOC instances. looks at potential tools available for overcoming the deployment challenges induced by large certificates and long certificate chains and discusses solutions available to overcome these challenges. gives examples of IoT and Web certificates as well as examples on how effective C509 and TLS certificate compression is at compressing example certificate and certificate chains. and describe how TLS clients or servers can reduce the size of the TLS handshake by not sending certificate authority certificates. proposes new optimized encodings for key exchange and signatures with P-256 in TLS 1.3.

Underlying Layers The described overheads in and are independent of the underlying layers as they do not consider DTLS handshake message fragmentation, how to compose DTLS handshake messages into records, and how the underlying layers influence the choice of application plaintext sizes. The complete overhead for all layers depends on the combination of layers as well as assumptions regarding the devices and applications and is out of scope of the document. This section gives a short overview of the overheads of UDP, TCP, and CoAP to give the reader a high-level overview. DTLS and cTLS are typically sent over 8 bytes UDP datagram headers while TLS is typically sent over 20 bytes TCP segment headers. TCP also uses some more bytes for additional messages used in TCP internally. EDHOC is typically sent over CoAP which would typically add 12 bytes to flight #1, 5 bytes to flight #2, and 1 byte to flight #3 when used over OSCORE with the EDHOC + OSCORE combined request according to , see . If EDHOC is used without OSCORE, the overhead would typically be 12 bytes to flight #1 and #3 and 5 bytes to flight #2. OSCORE and Group OSCORE are part of CoAP and are typically sent over UDP. A comparison of the total size for DTLS and EDHOC when transported over IEEE 802.15.4 and 6LoWPAN is provided in . IPv6, UDP, and CoAP can be compressed with Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) . The use of SCHC can significantly reduce the overhead. gives an evaluation of how SCHC reduces this overhead for OSCORE and the DTLS 1.2 record layer when used in four of the most widely used LPWAN radio technologies Fragmentation can significantly increase the total overhead as many more packet headers have to be sent. CoAP, (D)TLS handshake, and IP support fragmentation. If, how, and where fragmentation is done depends heavily on the underlying layers.

Overhead of Authenticated Key Exchange Protocols This section analyzes and compares the sizes of key exchange flights for different protocols. To enable a comparison between protocols, the following assumptions are made:

• The overhead calculations in this section use an 8 bytes ICV (e.g., AES_128_CCM_8 or AES-CCM-16-64-128 ) or 16 bytes e.g., AES-CCM , AES-GCM , or ChaCha20-Poly1305 ).
• A minimum number of algorithms and cipher suites is offered. The algorithm used/offered are: P-256 or Curve25519 ; ECDSA with P-256 and SHA-256, or Ed25519 ; AES-CCM_8; and SHA-256 .
• The length of key identifiers is 1 byte.
• The length of connection identifiers is 1 byte.
• DTLS handshake message fragmentation is not considered.
• As many (D)TLS handshake messages as possible are sent in a single record.
• Only mandatory (D)TLS extensions are included.
• DoS protection with DTLS HelloVerifyRequest , HelloRetryRequest , or the CoAP Echo Option is not considered.

The choices of algorithms are based on the profiles in , , and on the used EDHOC application profiles, see Section 3.9 of . Many DTLS implementations splits flight #2 in two records. gives a short summary of the message overhead based on different parameters and some assumptions. The following sections detail the assumptions and the calculations.

Summary The DTLS, EDHOC, and cTLS overhead is dependent on the parameter Connection ID. The EDHOC and cTLS overhead is dependent on the key or certificate identifiers included. Key identifiers are byte strings used to identity a cryptographic key and certificate identifiers are used to identify a certificate. If 8 bytes identifiers are used instead of 1 byte, the RPK numbers for flight #2 and #3 increase by 7 bytes and the PSK numbers for flight #1 increase by 7 bytes. The TLS, DTLS, and cTLS overhead is dependent on the group used for key exchange and the signature algorithm. secp256r1 and ecdsa_secp256r1_sha256 have less optimized encoding than x25519, ed25519, and . compares the message sizes of DTLS 1.3, cTLS, and EDHOC handshakes with connection ID and the mandatory to implement algorithms CCM_8, P-256, and ECDSA . Editor's note: This version of the document analyses the -10 version of cTLS, which seems relatively stable.

Comparison of message sizes in bytes with CCM_8, P-256, and ECDSA and with Connection ID

compares the message sizes of DTLS 1.3 and TLS 1.3 handshakes without connection ID but with the same algorithms CCM_8, P-256, and ECDSA.

Comparison of message sizes in bytes with CCM_8, secp256r1, and ecdsa_secp256r1_sha256 or PSK and without Connection ID

is the same as but with more efficiently encoded key shares and signatures such as x25519 and ed25519. The algorithms in with point compressed secp256r1 RPKs would add 15 bytes to #2 and #3 in the rows with RPKs.

Comparison of message sizes in bytes with CCM_8, x25519, and ed25519 or PSK and without Connection ID

The numbers in , , and were calculated with 8 bytes tags, consistent with the algorithms that are mandatory to implement as per and Section 8 of . If 16 bytes tag are used, the numbers in the #2 and #3 columns increase by 8 bytes and the numbers in the Total column increase by 16 bytes. The numbers in , , and do not consider underlying layers, see .

DTLS 1.3 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 replaced with arbitrary strings or omitted, in which case their length is indicated. Values that are not arbitrary are given in hexadecimal.

Message Sizes RPK + ECDHE In this section, CCM_8, P-256, and ECDSA and a Connection ID of 1 byte are used.

Flight #1 DTLS 1.3 RPK + ECDHE flight #1 gives 185 bytes of overhead. With efficiently encoded key share such as x25519 or , the overhead is 185 - 33 = 152 bytes.

Flight #2 DTLS 1.3 RPK + ECDHE flight #2 gives 454 bytes of overhead. With a point compressed secp256r1 RPK, the overhead is 454 - 32 = 422 bytes, see . With an ed25519 RPK and signature, the overhead is 454 - 47 - 7 = 400 bytes. With an efficiently encoded key share such as x25519 or , the overhead is 454 - 33 = 421 bytes. With an efficiently encoded signature such , the overhead is 454 - 7 = 447 bytes. With x25519 and ed25519, the overhead is 454 - 47 - 33 - 7 = 367 bytes.

Flight #3 DTLS 1.3 RPK + ECDHE flight #3 gives 255 bytes of overhead. With a point compressed secp256r1 RPK, the overhead is 255 - 32 = 223 bytes, see . With an ed25519 RPK and signature, the overhead is 255 - 47 - 7 = 201 bytes. With an efficiently encoded signature such as , the overhead is 255 - 7 = 248 bytes.

Message Sizes PSK + ECDHE

Flight #1 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 219 bytes of overhead.

Flight #2 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 226 bytes of overhead.

Flight #3 The differences in overhead compared to are: The following is removed: In total: DTLS 1.3 PSK + ECDHE flight #3 gives 56 bytes of overhead.

Message Sizes PSK

Flight #1 The differences in overhead compared to are: The following is removed: In total: DTLS 1.3 PSK flight #1 gives 136 bytes of overhead.

Flight #2 The differences in overhead compared to are: The following is removed: In total: DTLS 1.3 PSK flight #2 gives 153 bytes of overhead.

Flight #3 There are no differences in overhead compared to . DTLS 1.3 PSK flight #3 gives 56 bytes of overhead.

Cached Information In this section, we consider the effect of on the message size overhead. Cached information can be used to use a cached server certificate from a previous connection and move bytes from flight #2 to flight #1. The cached certificate can be an RPK or X.509. The differences compared to are the following.

Flight #1 For the flight #1, the following is added: Giving a total of: In the case the cached certificate is X.509, the following is removed: Giving a total of:

Flight #2 For the flight #2, the following is added: And the following is reduced: 32 bytes) ]]> Giving a total of: In the case the cached certificate is X.509, the following is removed: Giving a total of:

Resumption To enable resumption, a 4th flight with the handshake message New Session Ticket is added to the DTLS handshake. Enabling resumption adds 41 bytes to the initial DTLS handshake. The resumption handshake is an ordinary PSK handshake with or without ECDHE.

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

Raw Public Keys Raw Public Keys in TLS consist of a DER encoded ASN.1 SubjectPublicKeyInfo structure . This section illustrates the format of P-256 (secp256r1) SubjectPublicKeyInfo with and without point compression as well as an ed25519 SubjectPublicKeyInfo. Point compression in SubjectPublicKeyInfo is standardized in and is therefore theoretically possible to use in PRKs and X.509 certificates used in (D)TLS but does not seem to be supported by (D)TLS implementations.

secp256r1 SubjectPublicKeyInfo Without Point Compression

secp256r1 SubjectPublicKeyInfo With Point Compression

ed25519 SubjectPublicKeyInfo

TLS 1.3 In this section, the message sizes are calculated for TLS 1.3. The major changes compared to DTLS 1.3 are a different record header, 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 ).

Message Sizes RPK + ECDHE In this section, CCM_8, x25519, and ed25519 are used.

Flight #1 TLS 1.3 RPK + ECDHE flight #1 gives 129 bytes of overhead.

Flight #2 TLS 1.3 RPK + ECDHE flight #2 gives 307 bytes of overhead.

Flight #3 TLS 1.3 RPK + ECDHE flight #3 gives 179 bytes of overhead.

Message Sizes PSK + ECDHE

Flight #1 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 163 bytes of overhead.

Flight #2 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.

Flight #3 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.

Message Sizes PSK

Flight #1 The differences in overhead compared to are: The following is removed: In total: TLS 1.3 PSK flight #1 gives 113 bytes of overhead.

Flight #2 The differences in overhead compared to are: The following is removed: In total: TLS 1.3 PSK flight #2 gives 117 bytes of overhead.

Flight #3 There are no differences in overhead compared to . TLS 1.3 PSK flight #3 gives 50 bytes of overhead.

TLS 1.2 and DTLS 1.2 The TLS 1.2 and DTLS 1.2 handshakes are not analyzed in detail in this document. One rough comparison of expected size between the TLS 1.2 and TLS 1.3 handshakes can be found by counting the number of bytes in the example handshakes of and . In these examples the server authenticates with a certificate and the client is not authenticated. In TLS 1.2, the number of bytes in the four flights are 170, 1188, 117, and 75 for a total of 1550 bytes. In TLS 1.3 the number of bytes in the three flights are 253, 1367, and 79 for a total of 1699 bytes. In general, the (D)TLS 1.2 and (D)TLS 1.3 handshakes can be expected to have similar number of bytes.

cTLS Version -10 of the cTLS specification has a single example with CCM_8, x25519, and ed25519 in Appendix A. This document uses that example and calculates numbers for different parameters as follows: Using secp256r1 instead of x25519 adds 33 bytes to the KeyShareEntry.key_exchange in flight #1 and flight #2. Using ecdsa_secp256r1_sha256 instead of ed25519 adds an average of 7 bytes to CertificateVerify.signature in flight #2 and flight #3. Using PSK authentication instead of ed25519 adds 1 byte (psk identifier) to flight #1 and removes 71 bytes (certificate and certificate_verify) from flight #2 and #3. Using PSK key exchange x25519 removes 32 bytes (KeyShareEntry.key_exchange) from flight #1 and #2. Using Connection ID adds 1 byte to flight #1 and #3, and 2 bytes to flight #2.

EDHOC This section gives an estimate of the message sizes of EDHOC authenticated with static Diffie-Hellman keys and where the static Diffie-Hellman keys are identified with a key identifier (kid). All examples are given in CBOR diagnostic notation and hexadecimal and are based on the test vectors in Section 4 of .

Message Sizes RPK

message_1

message_2

message_3

Summary Based on the example above it is relatively easy to calculate numbers also for EDHOC authenticated with signature keys and for authentication keys identified with a SHA-256/64 hash (x5t). Signatures increase the size of flight #2 and #3 by 57 (64 - 8 + 1) or 58 bytes, while x5t increases the size by 13-14 bytes compared to kid. The typical message sizes for the previous example and for the other combinations are summarized in . Note that EDHOC treats authentication keys stored in RPK and X.509 in the same way. More detailed examples can be found in .

Typical EDHOC message sizes in bytes

Summary 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 due to 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.

Overhead for Protection of Application Data To enable comparison, all the overhead calculations in this section use an 8 bytes ICV (e.g., AES_128_CCM_8 or AES-CCM-16-64-128 ) or 16 bytes (e.g., AES-CCM , AES-GCM , or ChaCha20-Poly1305 ), 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 (where applicable), 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, ID Context, and Sequence Number (where applicable). cTLS uses the DTLS 1.3 record layer. 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.

Summary 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, and for an ID Context of zero-length.

Overhead (8 bytes ICV) in bytes as a function of sequence number (Connection/Sender ID = '')

Overhead (8 bytes ICV) in bytes as a function of Connection/Sender ID (Sequence Number = '05')

Overhead (excluding ICV) in bytes (Connection/Sender ID = '', Sequence Number = '05')

The numbers in , , and do not consider the different Token processing requirements for clients required for secure operation as motivated by . As reuse of Tokens is easier in OSCORE than DTLS, OSCORE might have slightly lower overhead than DTLS 1.3 for long connection even if DTLS 1.3 has slightly lower overhead than OSCORE for short connections. The mechanism in reduces the overhead of uncompressed TLS 1.3 records by 3 bytes. The numbers in and were calculated with 8 bytes ICV which is the mandatory to implement in , and Section 8 of . If 16 bytes tag are used, all numbers increases by 8. The numbers in , , and do not consider underlying layers, see .

DTLS 1.2

DTLS 1.2 (Basic) This section analyzes the overhead of DTLS 1.2 . The nonce follows the strict profiling given in . This example is taken directly from , Figure 16. DTLS 1.2 gives 29 bytes overhead.

DTLS 1.2 with 6LoWPAN-GHC 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.

DTLS 1.2 with Connection ID This section analyzes the overhead of DTLS 1.2 with Connection ID . The overhead calculations in this section use Connection ID = '42'. DTLS record 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.

DTLS 1.2 with Connection ID and 6LoWPAN-GHC 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.

DTLS 1.3

DTLS 1.3 (Basic) 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 signaling bits, optional omission of length, reduction of sequence number into a 1 or 2-bytes field. DTLS 1.3 is only analyzed with an omitted length field and with an 8-bit sequence number (see Figure 4 of ). DTLS 1.3 gives 11 bytes overhead.

DTLS 1.3 with 6LoWPAN-GHC 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.

DTLS 1.3 with Connection ID 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.

DTLS 1.3 with Connection ID and 6LoWPAN-GHC 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.

TLS 1.2

TLS 1.2 (Basic) 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.

TLS 1.2 with 6LoWPAN-GHC 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.

TLS 1.3

TLS 1.3 (Basic) 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.

TLS 1.3 with 6LoWPAN-GHC 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.

OSCORE 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.

Group OSCORE This section analyzes the overhead of Group OSCORE . Group OSCORE defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. An additional requirement compared to is that ID Context is always included in requests. For example, if the length of the ID Context is 1 byte and the length of the Sender ID is 1 byte, this adds 2 bytes to requests. The below calculation Option Delta = ‘9’, ID Context = ‘’, Sender ID = ‘42’, and Sequence Number = ‘05’, and is only an example. ID Context = ‘’ would be the standard for local deployments only having a single group. The pairwise mode OSCORE with the above parameters gives 15 bytes overhead for requests and 11 bytes overhead for responses.

Summary 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. As it can be seen in , Group OSCORE for pairwise communication increases the overhead of OSCORE requests by 20%. Note that the compared protocols have slightly different use cases. TLS and DTLS are designed for the transport layer and are terminated at 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 communication in a group.

Security Considerations When using the security protocols outlined in this document, it is important to adhere to the latest requirements and recommendations for the respective protocol. It is also crucial to utilize supported versions of libraries that continue to receive security updates in response to identified vulnerabilities. While the security considerations provided in DTLS 1.2 , DTLS 1.3 , TLS 1.2 , TLS 1.3 , cTLS , EDHOC , OSCORE , Group OSCORE , and X.509 serve as a good starting point, they are not sufficient due to the fact that some of these specifications were authored many years ago. For instance, being compliant to the TLS 1.2 specification is considered very poor security practice, given that the mandatory-to-implement cipher suite TLS_RSA_WITH_AES_128_CBC_SHA possesses at least three major weaknesses. Therefore, implementations and configurations must also align with the latest recommendations and best practices. Notable examples when this document was published include BCP 195 , , and .

IANA Considerations This document has no actions for IANA.

Informative References This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. [STANDARDS-TRACK] This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload. This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG). This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information. A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1. This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session, then the receiver will be unable to locate the correct security context. The new ciphertext record format with the CID also provides content type encryption and record layer padding. This document updates RFC 6347. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended). The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem. This document looks at this problem in detail and describes the potential solutions available. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. This document contains example traces of Ephemeral Diffie-Hellman Over COSE (EDHOC). Internet communications and applications have both environmental costs and benefits. The IAB ran an online workshop in December 2022 to explore and understand these impacts. The role of the workshop was to discuss the impacts and the evolving industry needs, and to identify areas for improvements and future work. A key goal of the workshop was to call further attention to the topic and bring together a diverse stakeholder community to discuss these issues. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. Ericsson AB Ericsson AB Ericsson AB Ericsson AB Being able to securely retrieve information from sensors and control actuators while providing guards against distributed denial-of- service (DDoS) attacks are key requirements for CoAP deployments. To that aim, a security protocol (e.g., DTLS, TLS, or OSCORE) can be enabled to ensure secure CoAP operation, including protection against many attacks. This document identifies a set of known CoAP attacks and shows that simply using CoAP with a security protocol is not always enough for secure operation. Several of the identified attacks can be mitigated with a security protocol providing confidentiality and integrity combined with the solutions specified in RFC 9175. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP-mappable HTTP. Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 Certificate Signing Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. Inria Ericsson AB Ericsson AB Odin Solutions S.L. This document compiles the requirements for a lightweight authenticated key exchange protocol for OSCORE. This draft has completed a working group last call (WGLC) in the LAKE working group. Post-WGLC, the requirements are considered sufficiently stable for the working group to proceed with its work. It is not currently planned to publish this draft as an RFC. RISE AB IMT Atlantique Nokia Bell Labs Consultant This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. This document replaces and obsoletes RFC 8824. Windy Hill Systems, LLC Cisco Meta Platforms, Inc. This document specifies a "compact" version of TLS 1.3 and DTLS 1.3. It saves bandwidth by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS 1.3 or DTLS 1.3 since the over-the-wire framing is different. A single server can, however, offer cTLS alongside TLS or DTLS. Mozilla This draft defines a new TLS Certificate Compression scheme which uses a shared dictionary of root and intermediate WebPKI certificates. The scheme smooths the transition to post-quantum certificates by eliminating the root and intermediate certificates from the TLS certificate chain without impacting trust negotiation. It also delivers better compression than alternative proposals whilst ensuring fair treatment for both CAs and website operators. It may also be useful in other applications which store certificate chains, e.g. Certificate Transparency logs. Ericsson Siemens Münster Univ. of Applied Sciences TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to 2^14 + 1 bytes, which includes one byte for the content type. Records also have a 3-byte overhead due to the fixed opaque_type and legacy_record_version fields. This document defines a TLS extension that allows endpoints to negotiate a larger maximum inner plaintext size, up to 2^32 - 256 bytes, while reducing overhead. University of Applied Sciences Bonn-Rhein-Sieg Linaro Sandelman Software Works This document is a companion to RFC 7925 and defines TLS/DTLS 1.3 profiles for Internet of Things devices. It also updates RFC 7925 with regards to the X.509 certificate profile and ciphersuite requirements. AWS AWS Cloudflare Mozilla A TLS client or server that has access to the complete set of published intermediate certificates can inform its peer to avoid sending certificate authority certificates, thus reducing the size of the TLS handshake. Ericsson AB The encodings used in the ECDHE groups secp256r1, secp384r1, and secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant overhead and the ECDSA encoding produces variable-length signatures. This document defines new optimal fixed-length encodings and registers new ECDHE groups and ECDSA signature algorithms using these new encodings. The new encodings reduce the size of the ECDHE groups with 33, 49, and 67 bytes and the ECDSA algorithms with an average of 7 bytes. These new encodings also work in DTLS 1.3 and are especially useful in cTLS. n.d. n.d. n.d.

EDHOC Over CoAP and OSCORE The overhead of CoAP and OSCORE when used to transport EDHOC is a bit more complex than the overhead of UPD and TCP. Assuming that the CoAP Token has a length of 0 bytes, that the CoAP Content-Format is not used, that the EDHOC Initiator is the CoAP client, that the connection identifiers have 1-byte encodings, and that the CoAP URI path is "edhoc", the additional overhead due to CoAP being used as transport is: For EDHOC message_3 over OSCORE with the EDHOC + OSCORE combined request all the overhead contributions from the previous case is gone. The only additional overhead is 1 byte due to the EDHOC CoAP option.

Change Log Changes from -07 to -08:

• Editorial changes including updated references.

Changes from -06 to -07:

• Updated to cTLS-10
• Added reference to draft-mattsson-tls-super-jumbo-record-limit
• Updated to newer version of BSI document

Changes from -05 to -06:

• Editorial changes.

Changes from -04 to -05:

• Editorial changes.

Changes from -03 to -04:

• Added change log
• Updated to cTLS-09, which seems relatively stable.
• Explained key and certificate identifiers.
• Added a paragraph to introduce the section on underlying layers.
• Added text explaining the difference between AKEs and protocols for protection of application data.
• Added reference to RFC 7250, RFC 9547, and "Performance Comparison of EDHOC and DTLS 1.3 in Internet-of-Things Environments".
• Editorial changes.

Changes from -02 to -03:

• Security considerations linking to the security considerations for the protocols as well as newer recommendations and best practices.
• Moved "EDHOC Over CoAP and OSCORE" subsection to appendix.
• References for the algorithms.
• Editorial changes.

Changes from -01 to -02:

• More information about overhead in underlying layers.
• New subsection "EDHOC Over CoAP and OSCORE" contributed by Marco.
• Editorial changes.

Changes from -00 to -01:

• Added links to the IOTOPS mailing list and the GitHub repository.
• Made it clearer that the document focuses on comparing the security protocols and not underlying layers.
• Added a short section on underlying layers. Added references to SCHC documents.
• Changed “Conclusion” to “Summary”.
• Corrected Group OSCORE numbers.
• Updated cTLS numbers to align with -08. Use “cTLS-08” in tables to make it clear that numbers are for -08.
• cTLS is more stable now. Seems like cTLS will not optimize P-256/ECDSA and instead focus on x25519 and EdDSA. The impact of any cTLS changes are now much smaller than before.
• Editorial changes.

Acknowledgments The authors want to thank , , , , , , , , , , , , and for comments and suggestions on previous versions of the draft. All 6LoWPAN-GHC compression was done with . as a was a useful resource for the TLS handshake content and formatting and was a useful resource for SubjectPublicKeyInfo formatting.