Comparison of CoAP Security Protocols
Internet-Draft draft-ietf-iotops-security-protocol-comparison-07
John Preuß Mattsson
Ericsson
john.mattsson@ericsson.com
Francesca Palombini
Ericsson
francesca.palombini@ericsson.com
Mališa Vučinić
INRIA
malisa.vucinic@inria.fr
05 November 2024
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 https://datatracker.ietf.org/doc/draft-ietf-iotops-security-protocol-comparison/.
Discussion of this document takes place on the IOT Operations (iotops) Working Group mailing list (mailto:iotops@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/iotops/. Subscribe at https://www.ietf.org/mailman/listinfo/iotops/.
Source for this draft and an issue tracker can be found at https://github.com/lwig-wg/protocol-comparison.
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 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 frames can be sent (or resent 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 [RFC8376] and [I-D.ietf-lake-reqs].
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), COSE (COSE, C509), LAKE (EDHOC), LPWAN (SCHC), ROLL (RPL), and TLS (cTLS). Compact formats and protocol have also been suggested as a way to decrease the energy consumption of Internet Applications and Systems in general [RFC9547].
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 [RFC7252] and TCP [RFC8323]. The analyzed security protocols are DTLS 1.2 [RFC6347], DTLS 1.3 [RFC9147], TLS 1.2 [RFC5246], TLS 1.3 [RFC8446], cTLS [I-D.ietf-tls-ctls], EDHOC [RFC9528] [I-D.ietf-core-oscore-edhoc], OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 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. Section 3 compares the overhead of mutually authenticated key exchange protocols, while Section 4 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 [RFC7400]. DTLS is analyzed with and without Connection ID [RFC9146]. Readers are expected to be familiar with some of the terms described in RFC 7925 [RFC7925], such as Integrity Check Value (ICV).
Readers of this document also might be interested in the following documents: [Illustrated-TLS12], [Illustrated-TLS13], [Illustrated-DTLS13], and [RFC9529] explain every byte in example TLS 1.2, TLS 1.3, DTLS 1.3, and EDHOC instances. [RFC9191] 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. [I-D.ietf-cose-cbor-encoded-cert] gives examples of IoT and Web certificates as well as examples on how effective C509 and TLS certificate compression [RFC8879] is at compressing example certificate and certificate chains. [I-D.ietf-tls-cert-abridge] and [I-D.kampanakis-tls-scas-latest] describe how TLS clients or servers can reduce the size of the TLS handshake by not sending certificate authority certificates. [I-D.mattsson-tls-compact-ecc] proposes new optimized encodings for key exchange and signatures with P-256 in TLS 1.3.
Underlying Layers
The described overheads in Section 3 and Section 4 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 give 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 in the combined mode with OSCORE according to [I-D.ietf-core-oscore-edhoc], see Appendix A. 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 is 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 [Performance].
IPv6, UDP, and CoAP can be compressed with the Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) [RFC8824][I-D.ietf-schc-8824-update]. Use of SCHC can significantly reduce the overhead. [SCHC-eval] 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 supports 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 [RFC6655] or AES-CCM-16-64-128 [RFC9053]) or 16 bytes e.g., AES-CCM [SP-800-38C], AES-GCM [SP-800-38D], or ChaCha20-Poly1305 [RFC7539]).
- A minimum number of algorithms and cipher suites is offered. The algorithm used/offered are P-256 [SP-800-186] or Curve25519 [RFC7748], ECDSA [FIPS-186-5] with P-256 and SHA-256 or Ed25519 [RFC8032], AES-CCM_8, and SHA-256 [FIPS-180-4].
- The length of key identifiers are 1 byte.
- The length of connection identifiers are 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 HelloRetryRequest or the CoAP Echo Option is not considered.
The choices of algorithms are based on the profiles in [RFC7925], [I-D.ietf-uta-tls13-iot-profile], and [I-D.ietf-core-oscore-edhoc]. Many DTLS implementations splits flight #2 in two records.
Section 3.1 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 increases with 7 bytes and the PSK numbers for flight #1 increases with 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 [I-D.mattsson-tls-compact-ecc].
Figure 1 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 [I-D.ietf-uta-tls13-iot-profile] [I-D.ietf-core-oscore-edhoc].
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

Flight

#1

#2

#3

Total

DTLS

1.3
                  -

RPKs,

ECDHE

185

454

255

894

DTLS

1.3
                  -

Compressed

RPKs,

ECDHE

185

422

223

830

DTLS

1.3
                  -

Cached

RPK,

PRK,

ECDHE

224

402

255

881

DTLS

1.3
                  -

Cached

X.509,

RPK,

ECDHE

218

396

255

869

DTLS

1.3
                  -

PSK,

ECDHE

219

226

56

501

DTLS

1.3
                  -

PSK

136

153

56

345

EDHOC
                  -

Signature

X.509s,

x5t,

ECDHE

37

115

90

242

EDHOC
                  -

Signature

RPKs,

kid,

ECDHE

37

102

77

216

EDHOC
                  -

Static

DH

X.509s,

x5t,

ECDHE

37

58

33

128

EDHOC
                  -

Static

DH

RPKs,

kid,

ECDHE

37

45

19

101

=====================================================================
 Flight                                   #1      #2      #3   Total
---------------------------------------------------------------------
 DTLS 1.3 - RPKs, ECDHE                  185     454     255     894
 DTLS 1.3 - Compressed RPKs, ECDHE       185     422     223     830
 DTLS 1.3 - Cached RPK, PRK, ECDHE       224     402     255     881
 DTLS 1.3 - Cached X.509, RPK, ECDHE     218     396     255     869
 DTLS 1.3 - PSK, ECDHE                   219     226      56     501
 DTLS 1.3 - PSK                          136     153      56     345
---------------------------------------------------------------------
 EDHOC - Signature X.509s, x5t, ECDHE     37     115      90     242
 EDHOC - Signature RPKs,   kid, ECDHE     37     102      77     216
 EDHOC - Static DH X.509s, x5t, ECDHE     37      58      33     128
 EDHOC - Static DH RPKs,   kid, ECDHE     37      45      19     101
=====================================================================

Figure 2 compares of message sizes of DTLS 1.3 [RFC9147] and TLS 1.3 [RFC8446] 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

Flight

#1

#2

#3

Total

DTLS

1.3
                  -

RPKs,

ECDHE

179

447

254

880

DTLS

1.3
                  -

PSK,

ECDHE

213

219

55

487

DTLS

1.3
                  -

PSK

130

146

55

331

TLS

1.3
                  -

RPKs,

ECDHE

162

394

233

789

TLS

1.3
                  -

PSK,

ECDHE

196

190

50

436

TLS

1.3
                  -

PSK

113

117

50

280

cTLS-10
                  -

X.509s

by

reference,

ECDHE

107

200

98

405

cTLS-10
                  -

PSK,

ECDHE

108

120

20

250

cTLS-10
                  -

PSK

43

57

20

120

=====================================================================
 Flight                                   #1      #2      #3   Total
---------------------------------------------------------------------
 DTLS 1.3 - RPKs, ECDHE                  179     447     254     880
 DTLS 1.3 - PSK, ECDHE                   213     219      55     487
 DTLS 1.3 - PSK                          130     146      55     331
---------------------------------------------------------------------
 TLS 1.3  - RPKs, ECDHE                  162     394     233     789
 TLS 1.3  - PSK, ECDHE                   196     190      50     436
 TLS 1.3  - PSK                          113     117      50     280
---------------------------------------------------------------------
 cTLS-10  - X.509s by reference, ECDHE   107     200      98     405
 cTLS-10  - PSK, ECDHE                   108     120      20     250
 cTLS-10  - PSK                           43      57      20     120
=====================================================================

Figure 3 is the same as Figure 2 but with more efficiently encoded key shares and signatures such as x25519 and ed25519. The algorithms in [I-D.mattsson-tls-compact-ecc] 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

Flight

#1

#2

#3

Total

DTLS

1.3
                  -

RPKs,

ECDHE

146

360

200

706

DTLS

1.3
                  -

PSK,

ECDHE

180

186

55

421

DTLS

1.3
                  -

PSK

130

146

55

331

TLS

1.3
                  -

RPKs,

ECDHE

129

307

179

615

TLS

1.3
                  -

PSK,

ECDHE

163

157

50

370

TLS

1.3
                  -

PSK

113

117

50

280

cTLS-10
                  -

X.509s

by

reference,

ECDHE

74

160

91

325

cTLS-10
                  -

PSK,

ECDHE

75

89

20

186

cTLS-10
                  -

PSK

43

57

20

120

=====================================================================
 Flight                                   #1      #2      #3   Total
---------------------------------------------------------------------
 DTLS 1.3 - RPKs, ECDHE                  146     360     200     706
 DTLS 1.3 - PSK, ECDHE                   180     186      55     421
 DTLS 1.3 - PSK                          130     146      55     331
---------------------------------------------------------------------
 TLS 1.3  - RPKs, ECDHE                  129     307     179     615
 TLS 1.3  - PSK, ECDHE                   163     157      50     370
 TLS 1.3  - PSK                          113     117      50     280
---------------------------------------------------------------------
 cTLS-10  - X.509s by reference, ECDHE    74     160      91     325
 cTLS-10  - PSK, ECDHE                    75      89      20     186
 cTLS-10  - PSK                           43      57      20     120
=====================================================================

The numbers in Figure 2, Figure 2, and Figure 3 were calculated with 8 bytes tags which is the mandatory to implement in [I-D.ietf-uta-tls13-iot-profile] and [I-D.ietf-core-oscore-edhoc]. If 16 bytes tag are used, the numbers in the #2 and #3 columns increases with 8 and the numbers in the Total column increases with 16.
The numbers in Figure 1, Figure 2, and Figure 3 do not consider underlying layers, see Section 2.
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

Record Header - DTLSPlaintext (13 bytes):
16 fe fd EE EE SS SS SS SS SS SS LL LL

  Handshake Header - Client Hello (12 bytes):
  01 LL LL LL SS SS 00 00 00 LL LL LL

    Legacy Version (2 bytes):
    fe fd

    Client Random (32 bytes):
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
    14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

    Legacy Session ID (1 bytes):
    00

    Legacy Cookie (1 bytes):
    00

    Cipher Suites (TLS_AES_128_CCM_8_SHA256) (4 bytes):
    00 02 13 05

    Compression Methods (null) (2 bytes):
    01 00

    Extensions Length (2 bytes):
    LL LL

      Extension - Supported Groups (secp256r1) (8 bytes):
      00 0a 00 04 00 02 00 17

      Extension - Signature Algorithms (ecdsa_secp256r1_sha256)
      (8 bytes):
      00 0d 00 04 00 02 04 03

      Extension - Key Share (secp256r1) (75 bytes):
      00 33 00 27 00 25 00 1d 00 41
      04 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12
      13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 01 02 03 04 05 06
      07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a
      1b 1c 1d 1e 1f

      Extension - Supported Versions (1.3) (7 bytes):
      00 2b 00 03 02 03 04

      Extension - Client Certificate Type (Raw Public Key) (6 bytes):
      00 13 00 02 01 02

      Extension - Server Certificate Type (Raw Public Key) (6 bytes):
      00 14 00 02 01 02

      Extension - Connection Identifier (42) (6 bytes):
      00 36 00 02 01 42

13 + 12 + 2 + 32 + 1 + 1 + 4 + 2 + 2 + 8 + 8 + 75 + 7 + 6 + 6 + 6
= 185 bytes

DTLS 1.3 RPK + ECDHE flight #1 gives 185 bytes of overhead. With efficiently encoded key share such as x25519 or [I-D.mattsson-tls-compact-ecc] the overhead is 185 - 33 = 152 bytes.
Flight #2

Record Header - DTLSPlaintext (13 bytes):
16 fe fd EE EE SS SS SS SS SS SS LL LL

  Handshake Header - Server Hello (12 bytes):
  02 LL LL LL SS SS 00 00 00 LL LL LL

    Legacy Version (2 bytes):
    fe fd

    Server Random (32 bytes):
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
    14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

    Legacy Session ID (1 bytes):
    00

    Cipher Suite (TLS_AES_128_CCM_8_SHA256) (2 bytes):
    13 05

    Compression Method (null) (1 bytes):
    00

    Extensions Length (2 bytes):
    LL LL

      Extension - Key Share (secp256r1) (73 bytes):
      00 33 00 45 00 1d 00 41
      04 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12
      13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 01 02 03 04 05 06
      07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a
      1b 1c 1d 1e 1f

      Extension - Supported Versions (1.3) (6 bytes):
      00 2b 00 02 03 04

      Extension - Connection Identifier (43) (6 bytes):
      00 36 00 02 01 43

Record Header - DTLSCiphertext (3 bytes):
HH 42 SS

  Handshake Header - Encrypted Extensions (12 bytes):
  08 LL LL LL SS SS 00 00 00 LL LL LL

    Extensions Length (2 bytes):
    LL LL

      Extension - Client Certificate Type (Raw Public Key) (6 bytes):
      00 13 00 01 01 02

      Extension - Server Certificate Type (Raw Public Key) (6 bytes):
      00 14 00 01 01 02

  Handshake Header - Certificate Request (12 bytes):
  0d LL LL LL SS SS 00 00 00 LL LL LL

    Request Context (1 bytes):
    00

    Extensions Length (2 bytes):
    LL LL

      Extension - Signature Algorithms (ecdsa_secp256r1_sha256)
      (8 bytes):
      00 0d 00 04 00 02 08 07

  Handshake Header - Certificate (12 bytes):
  0b LL LL LL SS SS 00 00 00 LL LL LL

    Request Context (1 bytes):
    00

    Certificate List Length (3 bytes):
    LL LL LL

    Certificate Length (3 bytes):
    LL LL LL

    Certificate (Uncompressed secp256r1 RPK) (91 bytes):
    30 59 30 13 ... // DER encoded RPK, See Section 2.2.7.

    Certificate Extensions (2 bytes):
    00 00

  Handshake Header - Certificate Verify (12 bytes):
  0f LL LL LL SS SS 00 00 00 LL LL LL

    Signature (ecdsa_secp256r1_sha256) (average 75 bytes):
    04 03 LL LL
    30 LL 02 LL ... 02 LL ... // DER encoded signature

  Handshake Header - Finished (12 bytes):
  14 LL LL LL SS SS 00 00 00 LL LL LL

    Verify Data (32 bytes):
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
    14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

  Record Type (1 byte):
  16

Auth Tag (8 bytes):
e0 8b 0e 45 5a 35 0a e5

13 + 137 + 3 + 26 + 23 + 112 + 87 + 44 + 1 + 8 = 454 bytes

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 Section 3.2.7. With an ed25519 RPK and signature the overhead is 454 - 47 - 7 = 400 bytes. With an efficiently encoded key share such as x25519 or [I-D.mattsson-tls-compact-ecc] the overhead is 454 - 33 = 421 bytes. With an efficiently encoded signature such [I-D.mattsson-tls-compact-ecc] the overhead is 454 - 7 = 447 bytes. With x25519 and ed25519 he overhead is 454 - 47 - 33 - 7 = 367 bytes.
Flight #3

Record Header (3 bytes): // DTLSCiphertext
ZZ 43 SS

  Handshake Header - Certificate (12 bytes):
  0b LL LL LL SS SS XX XX XX LL LL LL

    Request Context (1 bytes):
    00

    Certificate List Length (3 bytes):
    LL LL LL

    Certificate Length (3 bytes):
    LL LL LL

    Certificate (Uncompressed secp256r1 RPK) (91 bytes):
    30 59 30 13 ... // DER encoded RPK, See Section 2.2.7.

    Certificate Extensions (2 bytes):
    00 00

  Handshake Header - Certificate Verify (12 bytes):
  0f LL LL LL SS SS 00 00 00 LL LL LL

    Signature (ecdsa_secp256r1_sha256) (average 75 bytes):
    04 03 LL LL
    30 LL 02 LL ... 02 LL ... // // DER encoded signature

  Handshake Header - Finished (12 bytes):
  14 LL LL LL SS SS 00 00 00 LL LL LL

    Verify Data (32 bytes) // SHA-256:
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
    14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

  Record Type (1 byte):
  16

Auth Tag (8 bytes) // AES-CCM_8:
00 01 02 03 04 05 06 07

3 + 112 + 87 + 44 + 1 + 8 = 255 bytes

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 Section 3.2.7. With an ed25519 RPK and signature the overhead is 255 - 47 - 7 = 201 bytes. With an efficiently encoded signature such as [I-D.mattsson-tls-compact-ecc] the overhead is 255 - 7 = 248 bytes.
Message Sizes PSK + ECDHE
Flight #1
The differences in overhead compared to Section 3.2.1.1 are:
The following is added:

+ Extension - PSK Key Exchange Modes (6 bytes):
  00 2d 00 02 01 01

+ Extension - Pre-Shared Key (48 bytes):
  00 29 00 2F
  00 0a 00 01 ID 00 00 00 00
  00 21 20 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
  11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

The following is removed:

- Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes)

- Extension - Client Certificate Type (Raw Public Key) (6 bytes)

- Extension - Server Certificate Type (Raw Public Key) (6 bytes)

In total:

185 + 6 + 48 - 8 - 6 - 6 = 219 bytes

DTLS 1.3 PSK + ECDHE flight #1 gives 219 bytes of overhead.
Flight #2
The differences in overhead compared to Section 3.2.1.2 are:
The following is added:

+ Extension - Pre-Shared Key (6 bytes)
  00 29 00 02 00 00

The following is removed:

- Handshake Message Certificate (112 bytes)

- Handshake Message CertificateVerify (87 bytes)

- Handshake Message CertificateRequest (23 bytes)

- Extension - Client Certificate Type (Raw Public Key) (6 bytes)

- Extension - Server Certificate Type (Raw Public Key) (6 bytes)

In total:

454 + 6 - 112 - 87 - 23 - 6 - 6 = 226 bytes

DTLS 1.3 PSK + ECDHE flight #2 gives 226 bytes of overhead.
Flight #3
The differences in overhead compared to Section 3.2.1.3 are:
The following is removed:

- Handshake Message Certificate (112 bytes)

- Handshake Message Certificate Verify (87 bytes)

In total:

255 - 112 - 87 = 56 bytes

DTLS 1.3 PSK + ECDHE flight #3 gives 56 bytes of overhead.
Message Sizes PSK
Flight #1
The differences in overhead compared to Section 3.2.2.1 are:
The following is removed:

- Extension - Supported Groups (x25519) (8 bytes)

- Extension - Key Share (75 bytes)

In total:

219 - 8 - 75 = 136 bytes

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

- Extension - Key Share (73 bytes)

In total:

226 - 73 = 153 bytes

DTLS 1.3 PSK flight #2 gives 153 bytes of overhead.
Flight #3
There are no differences in overhead compared to Section 3.2.2.3.
DTLS 1.3 PSK flight #3 gives 56 bytes of overhead.
Cached Information
In this section, we consider the effect of [RFC7924] 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 a RPK or X.509.
The differences compared to Section 3.2.1 are the following.
Flight #1
For the flight #1, the following is added:

+ Extension - Client Cashed Information (39 bytes):
  00 19 LL LL LL LL
  01 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11
  12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

Giving a total of:

185 + 39 = 224 bytes

In the case the cached certificate is X.509 the following is removed:

- Extension - Server Certificate Type (Raw Public Key) (6 bytes)

Giving a total of:

224 - 6 = 218 bytes

Flight #2
For the flight #2, the following is added:

+ Extension - Server Cashed Information (7 bytes):
  00 19 LL LL LL LL 01

And the following is reduced:

- Server Certificate (91 bytes -> 32 bytes)

Giving a total of:

454 + 7 - 59 = 402 bytes

In the case the cached certificate is X.509 the following is removed:

- Extension - Server Certificate Type (Raw Public Key) (6 bytes)

Giving a total of:

402 - 6 = 396 bytes

Resumption
To enable resumption, a 4th flight with the handshake message New Session Ticket is added to the DTLS handshake.

Record Header - DTLSCiphertext (3 bytes):
HH 42 SS

  Handshake Header - New Session Ticket (12 bytes):
  04 LL LL LL SS SS 00 00 00 LL LL LL

    Ticket Lifetime (4 bytes):
    00 01 02 03

    Ticket Age Add (4 bytes):
    00 01 02 03

    Ticket Nonce (2 bytes):
    01 00

    Ticket (6 bytes):
    00 04 ID ID ID ID

    Extensions (2 bytes):
    00 00

Auth Tag (8 bytes) // AES-CCM_8:
00 01 02 03 04 05 06 07

3 + 12 + 4 + 4 + 2 + 6 + 2 + 8 = 41 bytes

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 changes as follows.

DTLS 1.3 flight #1:   -6 bytes
DTLS 1.3 flight #2:   -7 bytes
DTLS 1.3 flight #3:   -1 byte

Raw Public Keys
Raw Public Keys in TLS consists of a DER encoded ASN.1 SubjectPublicKeyInfo structure [RFC7250]. This section illustrates the format of P-256 (secp256r1) SubjectPublicKeyInfo [RFC5480] with and without point compression as well as an ed25519 SubjectPublicKeyInfo. Point compression in SubjectPublicKeyInfo is standardized in [RFC5480] 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

0x30 // Sequence
0x59 // Size 89

0x30 // Sequence
0x13 // Size 19
0x06 0x07 0x2A 0x86 0x48 0xCE 0x3D 0x02 0x01
     // OID 1.2.840.10045.2.1 (ecPublicKey)
0x06 0x08 0x2A 0x86 0x48 0xCE 0x3D 0x03 0x01 0x07
     // OID 1.2.840.10045.3.1.7 (secp256r1)

0x03 // Bit string
0x42 // Size 66
0x00 // Unused bits 0
0x04 // Uncompressed
...... 64 bytes X and Y

Total of 91 bytes

secp256r1 SubjectPublicKeyInfo With Point Compression

0x30 // Sequence
0x39 // Size 57

0x30 // Sequence
0x13 // Size 19
0x06 0x07 0x2A 0x86 0x48 0xCE 0x3D 0x02 0x01
     // OID 1.2.840.10045.2.1 (ecPublicKey)
0x06 0x08 0x2A 0x86 0x48 0xCE 0x3D 0x03 0x01 0x07
     // OID 1.2.840.10045.3.1.7 (secp256r1)

0x03 // Bit string
0x22 // Size 34
0x00 // Unused bits 0
0x03 // Compressed
...... 32 bytes X

Total of 59 bytes

ed25519 SubjectPublicKeyInfo

0x30 // Sequence
0x2A // Size 42

0x30 // Sequence
0x05 // Size 5
0x06 0x03 0x2B 0x65 0x70
     // OID 1.3.101.112 (ed25519)

0x03 // Bit string
0x21 // Size 33
0x00 // Unused bits 0
...... 32 bytes

Total of 44 bytes

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 [I-D.ietf-tls-ctls]).
Message Sizes RPK + ECDHE
In this section, CCM_8, x25519, and ed25519 are used.
Flight #1

Record Header - TLSPlaintext (5 bytes):
16 03 03 LL LL

  Handshake Header - Client Hello (4 bytes):
  01 LL LL LL

    Legacy Version (2 bytes):
    03 03

    Client Random (32 bytes):
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
    14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

    Legacy Session ID (1 bytes):
    00

    Cipher Suites (TLS_AES_128_CCM_8_SHA256) (4 bytes):
    00 02 13 05

    Compression Methods (null) (2 bytes):
    01 00

    Extensions Length (2 bytes):
    LL LL

      Extension - Supported Groups (x25519) (8 bytes):
      00 0a 00 04 00 02 00 1d

      Extension - Signature Algorithms (ed25519)
      (8 bytes):
      00 0d 00 04 00 02 08 07

      Extension - Key Share (x25519) (42 bytes):
      00 33 00 26 00 24 00 1d 00 20
      00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
      14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

      Extension - Supported Versions (1.3) (7 bytes):
      00 2b 00 03 02 03 04

      Extension - Client Certificate Type (Raw Public Key) (6 bytes):
      00 13 00 01 01 02

      Extension - Server Certificate Type (Raw Public Key) (6 bytes):
      00 14 00 01 01 02

5 + 4 + 2 + 32 + 1 + 4 + 2 + 2 + 8 + 8 + 42 + 7 + 6 + 6 = 129 bytes

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

Record Header - TLSPlaintext (5 bytes):
16 03 03 LL LL

  Handshake Header - Server Hello (4 bytes):
  02 LL LL LL

    Legacy Version (2 bytes):
    fe fd

    Server Random (32 bytes):
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
    14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

    Legacy Session ID (1 bytes):
    00

    Cipher Suite (TLS_AES_128_CCM_8_SHA256) (2 bytes):
    13 05

    Compression Method (null) (1 bytes):
    00

    Extensions Length (2 bytes):
    LL LL

      Extension - Key Share (x25519) (40 bytes):
      00 33 00 24 00 1d 00 20
      00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
      14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

      Extension - Supported Versions (1.3) (6 bytes):
      00 2b 00 02 03 04

Record Header - TLSCiphertext (5 bytes):
17 03 03 LL LL

  Handshake Header - Encrypted Extensions (4 bytes):
  08 LL LL LL

    Extensions Length (2 bytes):
    LL LL

      Extension - Client Certificate Type (Raw Public Key) (6 bytes):
      00 13 00 01 01 02

      Extension - Server Certificate Type (Raw Public Key) (6 bytes):
      00 14 00 01 01 02

  Handshake Header - Certificate Request (4 bytes):
  0d LL LL LL

    Request Context (1 bytes):
    00

    Extensions Length (2 bytes):
    LL LL

      Extension - Signature Algorithms (ed25519)
      (8 bytes):
      00 0d 00 04 00 02 08 07

  Handshake Header - Certificate (4 bytes):
  0b LL LL LL

    Request Context (1 bytes):
    00

    Certificate List Length (3 bytes):
    LL LL LL

    Certificate Length (3 bytes):
    LL LL LL

    Certificate (ed25519 RPK) (44 bytes):
    30 2A 30 05 ... // DER encoded RPK, see Section 2.2.7.

    Certificate Extensions (2 bytes):
    00 00

  Handshake Header - Certificate Verify (4 bytes):
  0f LL LL LL

    Signature (ed25519) (68 bytes):
    08 07 LL LL
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
    14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

  Handshake Header - Finished (4 bytes):
  14 LL LL LL

    Verify Data (32 bytes):
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
    14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

  Record Type (1 byte):
  16

Auth Tag (8 bytes):
e0 8b 0e 45 5a 35 0a e5

5 + 90 + 5 + 18 + 15 + 57 + 72 + 36 + 1 + 8 = 307 bytes

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

Record Header - TLSCiphertext (5 bytes):
17 03 03 LL LL

  Handshake Header - Certificate (4 bytes):
  0b LL LL LL

    Request Context (1 bytes):
    00

    Certificate List Length (3 bytes):
    LL LL LL

    Certificate Length (3 bytes):
    LL LL LL

    Certificate (ed25519 RPK) (44 bytes):
    30 2A 30 05 ... // DER encoded RPK, see Section 2.2.7.

    Certificate Extensions (2 bytes):
    00 00

  Handshake Header - Certificate Verify (4 bytes):
  0f LL LL LL

    Signature (ed25519) (68 bytes):
    08 07 LL LL
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
    14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

  Handshake Header - Finished (4 bytes):
  14 LL LL LL

    Verify Data (32 bytes) // SHA-256:
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
    14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

  Record Type (1 byte)
  16

Auth Tag (8 bytes) // AES-CCM_8:
00 01 02 03 04 05 06 07

5 + 57 + 72 + 36 + 1 + 8 = 179 bytes

TLS 1.3 RPK + ECDHE flight #3 gives 179 bytes of overhead.
Message Sizes PSK + ECDHE
Flight #1
The differences in overhead compared to Section 3.3.1.3 are:
The following is added:

+ Extension - PSK Key Exchange Modes (6 bytes):
  00 2d 00 02 01 01

+ Extension - Pre-Shared Key (48 bytes):
  00 29 00 2F
  00 0a 00 01 ID 00 00 00 00
  00 21 20 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
  11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

The following is removed:

- Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes)

- Extension - Client Certificate Type (Raw Public Key) (6 bytes)

- Extension - Server Certificate Type (Raw Public Key) (6 bytes)

In total:

129 + 6 + 48 - 8 - 6 - 6 = 163 bytes

TLS 1.3 PSK + ECDHE flight #1 gives 163 bytes of overhead.
Flight #2
The differences in overhead compared to Section 3.3.1.2 are:
The following is added:

+ Extension - Pre-Shared Key (6 bytes)
  00 29 00 02 00 00

The following is removed:

- Handshake Message Certificate (57 bytes)

- Handshake Message CertificateVerify (72 bytes)

- Handshake Message CertificateRequest (15 bytes)

- Extension - Client Certificate Type (Raw Public Key) (6 bytes)

- Extension - Server Certificate Type (Raw Public Key) (6 bytes)

In total:

307 - 57 - 72 - 15 - 6 - 6  + 6 = 157 bytes

TLS 1.3 PSK + ECDHE flight #2 gives 157 bytes of overhead.
Flight #3
The differences in overhead compared to Section 3.3.1.3 are:
The following is removed:

- Handshake Message Certificate (57 bytes)

- Handshake Message Certificate Verify (72 bytes)

In total:

179 - 57 - 72 = 50 bytes

TLS 1.3 PSK + ECDHE flight #3 gives 50 bytes of overhead.
Message Sizes PSK
Flight #1
The differences in overhead compared to Section 3.3.2.1 are:
The following is removed:

- Extension - Supported Groups (x25519) (8 bytes)

- Extension - Key Share (42 bytes)

In total:

163 - 8 - 42 = 113 bytes

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

- Extension - Key Share (40 bytes)

In total:

157 - 40 = 117 bytes

TLS 1.3 PSK flight #2 gives 117 bytes of overhead.
Flight #3
There are no differences in overhead compared to Section 3.3.2.3.
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 on 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 [Illustrated-TLS12] and [Illustrated-TLS13]. 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 [I-D.ietf-tls-ctls] 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 x25519 add 33 bytes to the KeyShareEntry.key_exchange in flight #1 and flight #2.
Using ecdsa_secp256r1_sha256 instead ed25519 add an average of 7 bytes to CertificateVerify.signature in flight #2 and flight #3.
Using PSK authentication instead of ed25519 add 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 [RFC9528] authenticated with static Diffie-Hellman keys and where the static Diffie-Hellman 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 [RFC9529].
Message Sizes RPK
message_1

message_1 = (
  3,
  2,
  h'8af6f430ebe18d34184017a9a11bf511c8dff8f834730b96c1b7c8dbca2f
    c3b6',
  -24
)

message_1 (37 bytes):
03 02 58 20 8a f6 f4 30 eb e1 8d 34 18 40 17 a9 a1 1b f5 11 c8
df f8 f8 34 73 0b 96 c1 b7 c8 db ca 2f c3 b6 37

message_2

message_2 = (
  h'419701D7F00A26C2DC587A36DD752549F33763C893422C8EA0F955A13A4F
    F5D5042459E2DA6C75143F35',
  -8
)

message_2 (45 bytes):
 58 2a 41 97 01 d7 f0 0a 26 c2 dc 58 7a 36 dd 75 25 49 f3 37
 63 c8 93 42 2c 8e a0 f9 55 a1 3a 4f f5 d5 04 24 59 e2 da 6c
 75 14 3f 35 27

message_3

message_3 = (
  h'C2B62835DC9B1F53419C1D3A2261EEED3505'
)

message_3 (19 bytes):
52 c2 b6 28 35 dc 9b 1f 53 41 9c 1d 3a 22 61 ee ed 35 05

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 with (64 - 8 + 1) bytes while x5t increases the size with 13-14 bytes. The typical message sizes for the previous example and for the other combinations are summarized in Figure 4. Note that EDHOC treats authentication keys stored in RPK and X.509 in the same way. More detailed examples can be found in [RFC9529].
Typical message sizes in bytes

Static

DH

Keys

Signature

Keys

kid

x5t

kid

x5t

message_1

37

37

37

37

message_2

45

58

102

115

message_3

19

33

77

90

Total

101

128

216

242

==========================================================
                     Static DH Keys        Signature Keys
                    ----------------      ----------------
                     kid        x5t        kid        x5t
----------------------------------------------------------
 message_1            37         37         37         37
 message_2            45         58        102        115
 message_3            19         33         77         90
----------------------------------------------------------
 Total               101        128        216        242
==========================================================

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 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.
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 [RFC6655] or AES-CCM-16-64-128 [RFC9053]) or 16 bytes (e.g., AES-CCM [SP-800-38C], AES-GCM [SP-800-38D], or ChaCha20-Poly1305 [RFC7539]), a plaintext of 6 bytes, and the sequence number ‘05’. This follows the example in [RFC7400], 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.
Section 4.1 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.
Overhead (8 bytes ICV) in bytes as a function of sequence number (Connection/Sender ID = '')

Sequence

Number

'05'

'1005'

'100005'

DTLS

1.2

29

29

29

DTLS

1.3

11

11

11

DTLS

1.2

(GHC)

16

16

16

DTLS

1.3

(GHC)

12

12

12

TLS

1.2

21

21

21

TLS

1.3

14

14

14

TLS

1.2

(GHC)

17

18

19

TLS

1.3

(GHC)

15

16

17

OSCORE

request

13

14

15

OSCORE

response

11

11

11

Group

OSCORE

pairwise

request

14

15

16

Group

OSCORE

pairwise

response

11

11

11

===============================================================
 Sequence Number                  '05'      '1005'    '100005'
---------------------------------------------------------------
 DTLS 1.2                          29         29         29
 DTLS 1.3                          11         11         11
---------------------------------------------------------------
 DTLS 1.2 (GHC)                    16         16         16
 DTLS 1.3 (GHC)                    12         12         12
---------------------------------------------------------------
 TLS  1.2                          21         21         21
 TLS  1.3                          14         14         14
---------------------------------------------------------------
 TLS  1.2 (GHC)                    17         18         19
 TLS  1.3 (GHC)                    15         16         17
---------------------------------------------------------------
 OSCORE request                    13         14         15
 OSCORE response                   11         11         11
---------------------------------------------------------------
 Group OSCORE pairwise request     14         15         16
 Group OSCORE pairwise response    11         11         11
===============================================================

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

Connection/Sender

ID
                  ''

'42'

'4002'

DTLS

1.2

29

30

31

DTLS

1.3

11

12

13

DTLS

1.2

(GHC)

16

17

18

DTLS

1.3

(GHC)

12

13

14

OSCORE

request

13

14

15

OSCORE

response

11

11

11

Group

OSCORE

pairwise

request

14

15

16

Group

OSCORE

pairwise

response

11

11

11

==============================================================
 Connection/Sender ID              ''        '42'      '4002'
--------------------------------------------------------------
 DTLS 1.2                          29         30         31
 DTLS 1.3                          11         12         13
--------------------------------------------------------------
 DTLS 1.2 (GHC)                    16         17         18
 DTLS 1.3 (GHC)                    12         13         14
--------------------------------------------------------------
 OSCORE request                    13         14         15
 OSCORE response                   11         11         11
--------------------------------------------------------------
 Group OSCORE pairwise request     14         15         16
 Group OSCORE pairwise response    11         11         11
==============================================================

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

Protocol

Overhead

Overhead

(GHC)

DTLS

1.2

21

8

DTLS

1.3

3

4

TLS

1.2

13

9

TLS

1.3

6

7

OSCORE

request

5

OSCORE

response

3

Group

OSCORE

pairwise

request

6

Group

OSCORE

pairwise

response

3

=============================================================
 Protocol                       Overhead      Overhead (GHC)
-------------------------------------------------------------
 DTLS 1.2                          21               8
 DTLS 1.3                           3               4
-------------------------------------------------------------
 TLS  1.2                          13               9
 TLS  1.3                           6               7
-------------------------------------------------------------
 OSCORE request                     5
 OSCORE response                    3
-------------------------------------------------------------
 Group OSCORE pairwise request      6
 Group OSCORE pairwise response     3
=============================================================

The numbers in Figure 5, Figure 6, and {fig-overhead3} do not consider the different Token processing requirements for clients [RFC9175] required for secure operation as motivated by [I-D.ietf-core-attacks-on-coap]. 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 [I-D.mattsson-tls-super-jumbo-record-limit] reduces the overhead of uncompressed TLS 1.3 records with 3 bytes.
The numbers in Figure 5 and Figure 6 were calculated with 8 bytes ICV which is the mandatory to implement in [I-D.ietf-uta-tls13-iot-profile], and [I-D.ietf-core-oscore-edhoc]. If 16 bytes tag are used, all numbers increases with 8.
The numbers in Figure 5, Figure 6, and Figure 7 do not consider underlying layers, see Section 2.
DTLS 1.2
DTLS 1.2
This section analyzes the overhead of DTLS 1.2 [RFC6347]. The nonce follow the strict profiling given in [RFC7925]. This example is taken directly from [RFC7400], Figure 16.

DTLS 1.2 record layer (35 bytes, 29 bytes overhead):
17 fe fd 00 01 00 00 00 00 00 05 00 16 00 01 00
00 00 00 00 05 ae a0 15 56 67 92 4d ff 8a 24 e4
cb 35 b9

Content type:
17
Version:
fe fd
Epoch:
00 01
Sequence number:
00 00 00 00 00 05
Length:
00 16
Nonce:
00 01 00 00 00 00 00 05
Ciphertext:
ae a0 15 56 67 92
ICV:
4d ff 8a 24 e4 cb 35 b9

DTLS 1.2 gives 29 bytes overhead.
DTLS 1.2 with 6LoWPAN-GHC
This section analyzes the overhead of DTLS 1.2 [RFC6347] when compressed with 6LoWPAN-GHC [RFC7400]. The compression was done with [OlegHahm-ghc].
Note that the sequence number ‘01’ used in [RFC7400], 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.

Compressed DTLS 1.2 record layer (22 bytes, 16 bytes overhead):
b0 c3 03 05 00 16 f2 0e ae a0 15 56 67 92 4d ff
8a 24 e4 cb 35 b9

Compressed DTLS 1.2 record layer header and nonce:
b0 c3 03 05 00 16 f2 0e
Ciphertext:
ae a0 15 56 67 92
ICV:
4d ff 8a 24 e4 cb 35 b9

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 [RFC6347] with Connection ID [RFC9146]. The overhead calculations in this section uses Connection ID = '42'. DTLS record layer with a Connection ID = '' (the empty string) is equal to DTLS without Connection ID.

DTLS 1.2 record layer (36 bytes, 30 bytes overhead):
17 fe fd 00 01 00 00 00 00 00 05 42 00 16 00 01
00 00 00 00 00 05 ae a0 15 56 67 92 4d ff 8a 24
e4 cb 35 b9

Content type:
17
Version:
fe fd
Epoch:
00 01
Sequence number:
00 00 00 00 00 05
Connection ID:
42
Length:
00 16
Nonce:
00 01 00 00 00 00 00 05
Ciphertext:
ae a0 15 56 67 92
ICV:
4d ff 8a 24 e4 cb 35 b9

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 [RFC6347] with Connection ID [RFC9146] when compressed with 6LoWPAN-GHC [RFC7400] [OlegHahm-ghc].
Note that the sequence number ‘01’ used in [RFC7400], 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.

Compressed DTLS 1.2 record layer (23 bytes, 17 bytes overhead):
b0 c3 04 05 42 00 16 f2 0e ae a0 15 56 67 92 4d
ff 8a 24 e4 cb 35 b9

Compressed DTLS 1.2 record layer header and nonce:
b0 c3 04 05 42 00 16 f2 0e
Ciphertext:
ae a0 15 56 67 92
ICV:
4d ff 8a 24 e4 cb 35 b9

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
This section analyzes the overhead of DTLS 1.3 [RFC9147]. 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 [RFC9147]).

DTLS 1.3 record layer (17 bytes, 11 bytes overhead):
21 05 ae a0 15 56 67 92 ec 4d ff 8a 24 e4 cb 35 b9

First byte (including epoch):
21
Sequence number:
05
Ciphertext (including encrypted content type):
ae a0 15 56 67 92 ec
ICV:
4d ff 8a 24 e4 cb 35 b9

DTLS 1.3 gives 11 bytes overhead.
DTLS 1.3 with 6LoWPAN-GHC
This section analyzes the overhead of DTLS 1.3 [RFC9147] when compressed with 6LoWPAN-GHC [RFC7400] [OlegHahm-ghc].
Note that this header compression is not available when DTLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC.

Compressed DTLS 1.3 record layer (18 bytes, 12 bytes overhead):
11 21 05 ae a0 15 56 67 92 ec 4d ff 8a 24 e4 cb
35 b9

Compressed DTLS 1.3 record layer header and nonce:
11 21 05
Ciphertext (including encrypted content type):
ae a0 15 56 67 92 ec
ICV:
4d ff 8a 24 e4 cb 35 b9

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 [RFC9147] with Connection ID [RFC9146].
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 [RFC9147]), with the addition of the Connection ID field.

DTLS 1.3 record layer (18 bytes, 12 bytes overhead):
31 42 05 ae a0 15 56 67 92 ec 4d ff 8a 24 e4 cb 35 b9

First byte (including epoch):
31
Connection ID:
42
Sequence number:
05
Ciphertext (including encrypted content type):
ae a0 15 56 67 92 ec
ICV:
4d ff 8a 24 e4 cb 35 b9

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 [RFC9147] with Connection ID [RFC9146] when compressed with 6LoWPAN-GHC [RFC7400] [OlegHahm-ghc].
Note that this header compression is not available when DTLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC.

Compressed DTLS 1.3 record layer (19 bytes, 13 bytes overhead):
12 31 05 42 ae a0 15 56 67 92 ec 4d ff 8a 24 e4
cb 35 b9

Compressed DTLS 1.3 record layer header and nonce:
12 31 05 42
Ciphertext (including encrypted content type):
ae a0 15 56 67 92 ec
ICV:
4d ff 8a 24 e4 cb 35 b9

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
This section analyzes the overhead of TLS 1.2 [RFC5246]. 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 Record Layer (27 bytes, 21 bytes overhead):
17 03 03 00 16 00 00 00 00 00 00 00 05 ae a0 15
56 67 92 4d ff 8a 24 e4 cb 35 b9

Content type:
17
Version:
03 03
Length:
00 16
Nonce:
00 00 00 00 00 00 00 05
Ciphertext:
ae a0 15 56 67 92
ICV:
4d ff 8a 24 e4 cb 35 b9

TLS 1.2 gives 21 bytes overhead.
TLS 1.2 with 6LoWPAN-GHC
This section analyzes the overhead of TLS 1.2 [RFC5246] when compressed with 6LoWPAN-GHC [RFC7400] [OlegHahm-ghc].
Note that this header compression is not available when TLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC.

Compressed TLS 1.2 record layer (23 bytes, 17 bytes overhead):
05 17 03 03 00 16 85 0f 05 ae a0 15 56 67 92 4d
ff 8a 24 e4 cb 35 b9

Compressed TLS 1.2 record layer header and nonce:
05 17 03 03 00 16 85 0f 05
Ciphertext:
ae a0 15 56 67 92
ICV:
4d ff 8a 24 e4 cb 35 b9

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
This section analyzes the overhead of TLS 1.3 [RFC8446]. The change compared to TLS 1.2 is that the TLS 1.3 record layer uses a different version.

TLS 1.3 Record Layer (20 bytes, 14 bytes overhead):
17 03 03 00 16 ae a0 15 56 67 92 ec 4d ff 8a 24
e4 cb 35 b9

Content type:
17
Legacy version:
03 03
Length:
00 0f
Ciphertext (including encrypted content type):
ae a0 15 56 67 92 ec
ICV:
4d ff 8a 24 e4 cb 35 b9

TLS 1.3 gives 14 bytes overhead.
TLS 1.3 with 6LoWPAN-GHC
This section analyzes the overhead of TLS 1.3 [RFC8446] when compressed with 6LoWPAN-GHC [RFC7400] [OlegHahm-ghc].
Note that this header compression is not available when TLS is used over transports that do not use 6LoWPAN together with 6LoWPAN-GHC.

Compressed TLS 1.3 record layer (21 bytes, 15 bytes overhead):
14 17 03 03 00 0f ae a0 15 56 67 92 ec 4d ff 8a
24 e4 cb 35 b9

Compressed TLS 1.3 record layer header and nonce:
14 17 03 03 00 0f
Ciphertext (including encrypted content type):
ae a0 15 56 67 92 ec
ICV:
4d ff 8a 24 e4 cb 35 b9

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 [RFC8613].
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.

OSCORE request (19 bytes, 13 bytes overhead):
92 09 05
ff ec ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9

CoAP option delta and length:
92
Option value (flag byte and sequence number):
09 05
Payload marker:
ff
Ciphertext (including encrypted code):
ec ae a0 15 56 67 92
ICV:
4d ff 8a 24 e4 cb 35 b9

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

OSCORE request (20 bytes, 14 bytes overhead):
93 09 05 42
ff ec ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9

CoAP option delta and length:
93
Option Value (flag byte, sequence number, and Sender ID):
09 05 42
Payload marker:
ff
Ciphertext (including encrypted code):
ec ae a0 15 56 67 92
ICV:
4d ff 8a 24 e4 cb 35 b9

The below calculation uses Option Delta = ‘9’.

OSCORE response (17 bytes, 11 bytes overhead):
90
ff ec ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9

CoAP delta and option length:
90
Option value:
-
Payload marker:
ff
Ciphertext (including encrypted code):
ec ae a0 15 56 67 92
ICV:
4d ff 8a 24 e4 cb 35 b9

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 [I-D.ietf-core-oscore-groupcomm]. 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 [RFC8613] is that ID Context is always included in requests. Assuming 1 byte ID Context and Sender ID 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.

OSCORE request (21 bytes, 15 bytes overhead):
93 09 05 42
ff ec ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9

CoAP option delta and length:
93
Option Value (flag byte, ID Context length, sequence nr, Sender ID):
19 00 05 42
Payload marker:
ff
Ciphertext (including encrypted code):
ec ae a0 15 56 67 92
ICV:
4d ff 8a 24 e4 cb 35 b9

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 can be seen in Figure 7, Group OSCORE for pairwise communication increases the overhead of OSCORE requests with 20%.
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 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 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 [RFC6347], DTLS 1.3 [RFC9147], TLS 1.2 [RFC5246], TLS 1.3 [RFC8446], cTLS [I-D.ietf-tls-ctls], EDHOC [RFC9528] [I-D.ietf-core-oscore-edhoc], OSCORE [RFC8613], Group OSCORE [I-D.ietf-core-oscore-groupcomm], and X.509 [RFC5280] 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 [RFC5246] 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 [RFC9325][RFC8996], [SP-800-52], and [BSI-TLS].
IANA Considerations
This document has no actions for IANA.
Informative References
[RFC5246]

The Transport Layer Security (TLS) Protocol Version 1.2
T. Dierks
E. Rescorla
August 2008
RFC 5246
DOI 10.17487/RFC5246
[RFC5280]

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
D. Cooper
S. Santesson
S. Farrell
S. Boeyen
R. Housley
W. Polk
May 2008
RFC 5280
DOI 10.17487/RFC5280
[RFC5480]

Elliptic Curve Cryptography Subject Public Key Information
S. Turner
D. Brown
K. Yiu
R. Housley
T. Polk
March 2009
RFC 5480
DOI 10.17487/RFC5480
[RFC6347]

Datagram Transport Layer Security Version 1.2
E. Rescorla
N. Modadugu
January 2012
RFC 6347
DOI 10.17487/RFC6347
[RFC6655]

AES-CCM Cipher Suites for Transport Layer Security (TLS)
D. McGrew
D. Bailey
July 2012
RFC 6655
DOI 10.17487/RFC6655
[RFC7250]

Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
P. Wouters, Ed.
H. Tschofenig, Ed.
J. Gilmore
S. Weiler
T. Kivinen
June 2014
RFC 7250
DOI 10.17487/RFC7250
[RFC7252]

The Constrained Application Protocol (CoAP)
Z. Shelby
K. Hartke
C. Bormann
June 2014
RFC 7252
DOI 10.17487/RFC7252
[RFC7400]

6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
C. Bormann
November 2014
RFC 7400
DOI 10.17487/RFC7400
[RFC7539]

ChaCha20 and Poly1305 for IETF Protocols
Y. Nir
A. Langley
May 2015
RFC 7539
DOI 10.17487/RFC7539
[RFC7748]

Elliptic Curves for Security
A. Langley
M. Hamburg
S. Turner
January 2016
RFC 7748
DOI 10.17487/RFC7748
[RFC7924]

Transport Layer Security (TLS) Cached Information Extension
S. Santesson
H. Tschofenig
July 2016
RFC 7924
DOI 10.17487/RFC7924
[RFC7925]

Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
H. Tschofenig, Ed.
T. Fossati
July 2016
RFC 7925
DOI 10.17487/RFC7925
[RFC8032]

Edwards-Curve Digital Signature Algorithm (EdDSA)
S. Josefsson
I. Liusvaara
January 2017
RFC 8032
DOI 10.17487/RFC8032
[RFC8323]

CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
C. Bormann
S. Lemay
H. Tschofenig
K. Hartke
B. Silverajan
B. Raymor, Ed.
February 2018
RFC 8323
DOI 10.17487/RFC8323
[RFC8376]

Low-Power Wide Area Network (LPWAN) Overview
S. Farrell, Ed.
May 2018
RFC 8376
DOI 10.17487/RFC8376
[RFC8446]

The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla
August 2018
RFC 8446
DOI 10.17487/RFC8446
[RFC8613]

Object Security for Constrained RESTful Environments (OSCORE)
G. Selander
J. Mattsson
F. Palombini
L. Seitz
July 2019
RFC 8613
DOI 10.17487/RFC8613
[RFC8824]

Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)
A. Minaburo
L. Toutain
R. Andreasen
June 2021
RFC 8824
DOI 10.17487/RFC8824
[RFC8879]

TLS Certificate Compression
A. Ghedini
V. Vasiliev
December 2020
RFC 8879
DOI 10.17487/RFC8879
[RFC8996]

Deprecating TLS 1.0 and TLS 1.1
K. Moriarty
S. Farrell
March 2021
BCP 195
RFC 8996
DOI 10.17487/RFC8996
[RFC9053]

CBOR Object Signing and Encryption (COSE): Initial Algorithms
J. Schaad
August 2022
RFC 9053
DOI 10.17487/RFC9053
[RFC9146]

Connection Identifier for DTLS 1.2
E. Rescorla, Ed.
H. Tschofenig, Ed.
T. Fossati
A. Kraus
March 2022
RFC 9146
DOI 10.17487/RFC9146
[RFC9147]

The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
E. Rescorla
H. Tschofenig
N. Modadugu
April 2022
RFC 9147
DOI 10.17487/RFC9147
[RFC9175]

Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing
C. Amsüss
J. Preuß Mattsson
G. Selander
February 2022
RFC 9175
DOI 10.17487/RFC9175
[RFC9191]

Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods
M. Sethi
J. Preuß Mattsson
S. Turner
February 2022
RFC 9191
DOI 10.17487/RFC9191
[RFC9325]

Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Y. Sheffer
P. Saint-Andre
T. Fossati
November 2022
BCP 195
RFC 9325
DOI 10.17487/RFC9325
[RFC9528]

Ephemeral Diffie-Hellman Over COSE (EDHOC)
G. Selander
J. Preuß Mattsson
F. Palombini
March 2024
RFC 9528
DOI 10.17487/RFC9528
[RFC9529]

Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC)
G. Selander
J. Preuß Mattsson
M. Serafin
M. Tiloca
M. Vučinić
March 2024
RFC 9529
DOI 10.17487/RFC9529
[RFC9547]

Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022
J. Arkko
C. S. Perkins
S. Krishnan
February 2024
RFC 9547
DOI 10.17487/RFC9547
[I-D.ietf-core-attacks-on-coap]

Attacks on the Constrained Application Protocol (CoAP)
John Preuß Mattsson
Ericsson AB
John Fornehed
Ericsson AB
Göran Selander
Ericsson AB
Francesca Palombini
Ericsson AB
Christian Amsüss
21 February 2024
Internet-Draft draft-ietf-core-attacks-on-coap-04
[I-D.ietf-core-oscore-edhoc]

Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)
Francesca Palombini
Ericsson
Marco Tiloca
RISE AB
Rikard Höglund
RISE AB
Stefan Hristozov
Fraunhofer AISEC
Göran Selander
Ericsson
9 April 2024
Internet-Draft draft-ietf-core-oscore-edhoc-11
[I-D.ietf-core-oscore-groupcomm]

Group Object Security for Constrained RESTful Environments (Group OSCORE)
Marco Tiloca
RISE AB
Göran Selander
Ericsson AB
Francesca Palombini
Ericsson AB
John Preuß Mattsson
Ericsson AB
Rikard Höglund
RISE AB
26 September 2024
Internet-Draft draft-ietf-core-oscore-groupcomm-23
[I-D.ietf-cose-cbor-encoded-cert]

CBOR Encoded X.509 Certificates (C509 Certificates)
John Preuß Mattsson
Ericsson AB
Göran Selander
Ericsson AB
Shahid Raza
RISE AB
Joel Höglund
RISE AB
Martin Furuhed
Nexus Group
8 July 2024
Internet-Draft draft-ietf-cose-cbor-encoded-cert-11
[I-D.ietf-lake-reqs]

Requirements for a Lightweight AKE for OSCORE
Mališa Vučinić
Inria
Göran Selander
Ericsson AB
John Preuß Mattsson
Ericsson AB
Dan Garcia-Carillo
Odin Solutions S.L.
8 June 2020
Internet-Draft draft-ietf-lake-reqs-04
[I-D.ietf-schc-8824-update]

Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)
Marco Tiloca
RISE AB
Laurent Toutain
IMT Atlantique
Ivan Martinez
Nokia Bell Labs
Ana Minaburo
Consultant
21 October 2024
Internet-Draft draft-ietf-schc-8824-update-03
[I-D.ietf-tls-ctls]

Compact TLS 1.3
Eric Rescorla
Windy Hill Systems, LLC
Richard Barnes
Cisco
Hannes Tschofenig
Benjamin M. Schwartz
Meta Platforms, Inc.
17 April 2024
Internet-Draft draft-ietf-tls-ctls-10
[I-D.ietf-tls-cert-abridge]

Abridged Compression for WebPKI Certificates
Dennis Jackson
Mozilla
16 September 2024
Internet-Draft draft-ietf-tls-cert-abridge-02
[I-D.ietf-uta-tls13-iot-profile]

TLS/DTLS 1.3 Profiles for the Internet of Things
Hannes Tschofenig
University of Applied Sciences Bonn-Rhein-Sieg
Thomas Fossati
Linaro
Michael Richardson
Sandelman Software Works
20 October 2024
Internet-Draft draft-ietf-uta-tls13-iot-profile-11
[I-D.kampanakis-tls-scas-latest]

Suppressing CA Certificates in TLS 1.3
Panos Kampanakis
AWS
Cameron Bytheway
AWS
Bas Westerbaan
Cloudflare
Martin Thomson
Mozilla
5 January 2023
Internet-Draft draft-kampanakis-tls-scas-latest-03
[I-D.mattsson-tls-compact-ecc]

Compact ECDHE and ECDSA Encodings for TLS 1.3
John Preuß Mattsson
Ericsson AB
Hannes Tschofenig
23 February 2024
Internet-Draft draft-mattsson-tls-compact-ecc-06
[I-D.mattsson-tls-super-jumbo-record-limit]

Large Record Sizes for TLS and DTLS with Reduced Overhead
John Preuß Mattsson
Ericsson
Hannes Tschofenig
Siemens
Michael Tüxen
Münster Univ. of Applied Sciences
5 September 2024
Internet-Draft draft-mattsson-tls-super-jumbo-record-limit-05
[SP-800-186]

Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters
L. Chen
D. Moody
K. Randall
A. Regenscheid
A. Robinson
February 2023
NIST Special Publication 800-186
[SP-800-52]

Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations
K. McKay
D. Cooper
August 2019
NIST Special Publication 800-52 Revision 2
[SP-800-38C]

Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality
M. Dworkin
May 2004
NIST Special Publication 800-38C
[SP-800-38D]

Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC
M. Dworkin
November 2007
NIST Special Publication 800-38D
[FIPS-180-4]

Secure Hash Standard (SHS)
NIST
August 2015
[FIPS-186-5]

Digital Signature Standard (DSS)
NIST
February 2023
[BSI-TLS]

Technical Guideline TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths Part 2 – Use of Transport Layer Security (TLS)
Bundesamt für Sicherheit in der Informationstechnik
February 2024
[SCHC-eval]

Effective interoperability and security support for constrained IoT networks
M. Dumay
D. Barthel
L. Toutain
J. Lecoeuvre
December 2021
[OlegHahm-ghc]

Generic Header Compression
O. Hahm
July 2016
[IoT-Cert]

Digital Certificates for the Internet of Things
F. Forsby
June 2017
[Illustrated-TLS12]

The Illustrated TLS 1.2 Connection
M. Driscoll
n.d.
[Illustrated-TLS13]

The Illustrated TLS 1.3 Connection
M. Driscoll
n.d.
[Illustrated-DTLS13]

The Illustrated DTLS 1.3 Connection
M. Driscoll
n.d.
[Performance]

Performance Comparison of EDHOC and DTLS 1.3 in Internet-of-Things Environments
G. Fedrecheski
M. Vučinić
T. Watteyne
January 2024
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 a that the CoAP Token has a length of 0 bytes, that CoAP Content-Format is not used, that the EDHOC Initiator is the CoAP client, that the connection identifiers have 1-byte encodings, and the CoAP URI path is "edhoc", the additional overhead due to CoAP being used as transport is:

For EDHOC message_1

--- CoAP header: 4 bytes
--- CoAP token: 0 bytes
--- URI-Path option with value "edhoc": 6 bytes
--- Payload marker 0xff: 1 byte
--- Dummy connection identifier "true": 1 byte

Total: 12 bytes

For EDHOC message_2

--- CoAP header: 4 bytes
--- CoAP token: 0 bytes
--- Payload marker 0xff: 1 byte

Total: 5 bytes

For EDHOC message_3 without the combined request

--- CoAP header: 4 bytes
--- CoAP token: 0 bytes
--- URI-Path option with value "edhoc": 6 bytes
--- Payload marker 0xff: 1 byte
--- Connection identifier C_R (wire encoding): 1 byte

Total: 12 bytes

For EDHOC message_3 over OSCORE with the EDHOC + OSCORE combined request [I-D.ietf-core-oscore-edhoc] 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 -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 Carsten Bormann, Russ Housley, Ari Keränen, Erik Kline, Stephan Koch, Achim Kraus, Michael Richardsson, Göran Selander, Bill Silverajan, Akram Sheriff, Marco Tiloca, and Hannes Tschofenig for comments and suggestions on previous versions of the draft.
All 6LoWPAN-GHC compression was done with [OlegHahm-ghc]. [Illustrated-TLS13] as a was a useful resource for the TLS handshake content and formatting and [IoT-Cert] was a useful resource for SubjectPublicKeyInfo formatting.