idnits 2.17.00 (12 Aug 2021) /tmp/idnits30090/draft-mattsson-t2trg-amplification-attacks-00.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(499): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(583): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 338: '...at "the receiver MUST NOT replace the ...' RFC 2119 keyword, line 344: '..."implementations MUST NOT update the a...' RFC 2119 keyword, line 429: '... QUIC [RFC9000] mandates that "an endpoint MUST limit the amount of...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (11 February 2022) is 92 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-lake-edhoc' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 542, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-core-conditional-attributes-01 == Outdated reference: draft-ietf-core-echo-request-tag has been published as RFC 9175 == Outdated reference: A later version (-06) exists of draft-ietf-core-groupcomm-bis-05 == Outdated reference: A later version (-14) exists of draft-ietf-core-oscore-groupcomm-13 == Outdated reference: A later version (-13) exists of draft-ietf-lake-edhoc-12 == Outdated reference: draft-ietf-tls-dtls-connection-id has been published as RFC 9146 == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Preuß Mattsson 3 Internet-Draft G. Selander 4 Intended status: Informational Ericsson 5 Expires: 15 August 2022 C. Amsüss 6 Energy Harvesting Solutions 7 11 February 2022 9 Amplification Attacks Using the Constrained Application Protocol (CoAP) 10 draft-mattsson-t2trg-amplification-attacks-00 12 Abstract 14 Protecting Internet of Things (IoT) devices against attacks is not 15 enough. IoT deployments need to make sure that they are not used for 16 Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are 17 typically done with compromised devices or with amplification attacks 18 using a spoofed source address. This document gives examples of 19 different theoretical amplification attacks using the Constrained 20 Application Protocol (CoAP). The goal with this document is to raise 21 awareness and to motivate generic and protocol-specific 22 recommendations on the usage of CoAP. Some of the discussed attacks 23 can be mitigated by not using NoSec or by using the Echo option. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 15 August 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Amplification Attacks using CoAP . . . . . . . . . . . . . . 3 57 2.1. Simple Amplification Attacks . . . . . . . . . . . . . . 4 58 2.2. Amplification Attacks using Observe . . . . . . . . . . . 5 59 2.3. Amplification Attacks using Group Requests . . . . . . . 7 60 2.4. MITM Amplification Attacks . . . . . . . . . . . . . . . 8 61 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 6. Informative References . . . . . . . . . . . . . . . . . . . 11 65 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 68 1. Introduction 70 One important protocol used to interact with Internet of Things (IoT) 71 sensors and actuators is the Constrained Application Protocol (CoAP) 72 [RFC7252]. CoAP can be used without security in the so called NoSec 73 mode but any Internet-of-Things (IoT) deployment valuing security and 74 privacy would use a security protocol such as DTLS 75 [I-D.ietf-tls-dtls13], TLS [RFC8446], or OSCORE [RFC8613] to protect 76 CoAP, where the choice of security protocol depends on the transport 77 protocol and the presence of intermediaries. The use of CoAP over 78 UDP and DTLS is specified in [RFC7252] and the use of CoAP over TCP 79 and TLS is specified in [RFC8323]. OSCORE protects CoAP end-to-end 80 with the use of COSE [RFC8152] and the CoAP Object-Security option 81 [RFC8613] and can therefore be used over any transport. Group OSCORE 82 [I-D.ietf-core-oscore-groupcomm] can be used to protect CoAP Group 83 Communication [I-D.ietf-core-groupcomm-bis]. 85 Protecting Internet of Things (IoT) devices against attacks is not 86 enough. IoT deployments need to make sure that they are not used for 87 Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are 88 typically done with compromised devices or with amplification attacks 89 using a spoofed source address. DDoS attacks is a huge and growing 90 problem for services and critical infrastucture [DDoS-Infra]. 92 The document gives examples of different theoretical amplification 93 attacks using CoAP. When transported over UDP, the CoAP NoSec mode 94 is susceptible to source IP address spoofing and as a single request 95 can result in multiple responses from multiple servers, CoAP can have 96 very large amplification factors. The goal with this document is to 97 raise awareness and to motivate generic and protocol-specific 98 recommendations on the usage of CoAP. 100 Some of the discussed attacks can be mitigated by not using NoSec or 101 by using the Echo option [I-D.ietf-core-echo-request-tag]. 103 2. Amplification Attacks using CoAP 105 In a Denial-of-Service (DoS) attack, an attacker sends a large number 106 of requests or responses to a target endpoint. The denial-of-service 107 might be caused by the target endpoint receiving a large amount of 108 data, sending a large amount of data, doing heavy processing, or 109 using too much memory, etc. In a Distributed Denial-of-Service 110 (DDoS) attack, the request or responses come from a large number of 111 sources. 113 In an amplification attack, the amplification factor is the ratio 114 between the total size of the data sent to the target and the total 115 size of the data sent by the attacker. In the attacks described in 116 this section, the attacker sends one or more requests, and the target 117 receives one or more responses. An amplification attack alone can be 118 a denial-of-service attack on a CoAP server by making it send a large 119 amount of data. But often amplification attacks are combined with 120 the attacker spoofing the source IP address of the targeted victim. 121 By requesting as much information as possible from several servers an 122 attacker can multiply the amount of traffic and create a distributed 123 denial-of-service attack on the target. When transported over UDP, 124 the CoAP NoSec mode is susceptible to source IP address spoofing. 126 Amplification attacks with CoAP are unfortunately not only theory. 127 Powerful CoAP amplification attacks made headlines in 2018, reaching 128 55 Gbps on average, and with the largest one clocking at 320 Gbps 129 [DDoS-ZDNET]. But in 2019, they were hardly seen anymore 130 [DDoS-2019]. In 2020, the FBI cyber division mentioned CoAP in a 131 public notification warning that cyber actors are increasingly likely 132 to abuse network protocols for DDoS attacks [DDoS-FBI]. CoAP 133 amplification attacks made a comeback in 2020 and CoAP was behind a 134 significant part of global DDoS attacks in Q4 2020 and Q1 2021, but 135 not at all in Q2 and Q3 of 2021 [DDoS-2021]. It seems unclear 136 exactly how the attacks were done, why they stopped, and how likely 137 CoAP amplifications attacks are to come back in the future. 139 The following sections give examples of different theoretical 140 amplification attacks using CoAP. 142 2.1. Simple Amplification Attacks 144 An amplification attack using a single response is illustrated in 145 Figure 1. If the response is c times larger than the request, the 146 amplification factor is c. 148 Client Foe Server 149 | | | 150 | +----->| Code: 0.01 (GET) 151 | | GET | Uri-Path: random quote 152 | | | 153 |<------------+ Code: 2.05 (Content) 154 | | 2.05 | Payload: "just because you own half the county 155 | | | doesn't mean that you have the power 156 | | | to run the rest of us. For twenty- 157 | | | three years, I've been dying to tell 158 | | | you what I thought of you! And now... 159 | | | well, being a Christian woman, I can't 160 | | | say it!" 162 Figure 1: Amplification attack using a single response 164 An attacker can increase the bandwidth by sending several GET 165 requests. An attacker can also increase or control the amplification 166 factor by creating or updating resources. By creating new resources, 167 an attacker can increase the size of /.well-known/core. An 168 amplification attack where the attacker influences the amplification 169 factor is illustrated in Figure 2. 171 Client Foe Server 172 | | | 173 | +----->| Code: 0.02 (POST) 174 | | POST | Uri-Path: /member/ 175 | | | Payload: hampsterdance.hevc 176 | | | 177 .... .... 178 | +----->| Code: 0.02 (GET) 179 | | GET | Uri-Path: /member/ 180 | | | 181 |<------------+ Code: 2.05 (Content) 182 | | 2.05 | Payload: hampsterdance.hevc 183 | | | 184 | +----->| Code: 0.02 (GET) 185 | | GET | Uri-Path: /member/ 186 | | | 187 |<------------+ Code: 2.05 (Content) 188 | | 2.05 | Payload: hampsterdance.hevc 189 .... .... 191 Figure 2: Amplification attack using several requests and a chosen 192 amplification factor 194 2.2. Amplification Attacks using Observe 196 Amplification factors can be significantly worse when combined with 197 observe [RFC7641] and group requests [I-D.ietf-core-groupcomm-bis]. 198 As a single request can result in multiple responses from multiple 199 servers, the amplification factors can be very large. 201 An amplification attack using observe is illustrated in Figure 3. If 202 each notification response is c times larger than the registration 203 request and each request results in n notifications, the 204 amplification factor is c * n. By registering the same client 205 several times using different Tokens or port numbers, the bandwidth 206 can be increased. By updating the observed resource, the attacker 207 may trigger notifications and increase the size of the notifications. 208 By using conditional attributes 209 [I-D.ietf-core-conditional-attributes] an attacker may increase the 210 frequency of notifications and therefore the amplification factor. 211 The maximum period attribute pmax indicates the maximum time, in 212 seconds, between two consecutive notifications (whether or not the 213 resource state has changed). If it is predictable when notifications 214 are sent as confirmable and which Message ID are used the 215 acknowledgements may be spoofed. 217 Client Foe Server 218 | | | 219 | +----->| Code: 0.01 (GET) 220 | | GET | Token: 0x83 221 | | | Observe: 0 222 | | | Uri-Path: temperature 223 | | | Uri-Query: pmax="0.1" 224 | | | 225 | +----->| Code: 0.01 (GET) 226 | | GET | Token: 0x84 227 | | | Observe: 0 228 | | | Uri-Path: temperature 229 | | | Uri-Query: pmax="0.1" 230 | | | 231 .... .... 232 |<------------+ Code: 2.05 (Content) 233 | | 2.05 | Token: 0x83 234 | | | Observe: 217362 235 | | | Payload: "299.7 K" 236 | | | 237 |<------------+ Code: 2.05 (Content) 238 | | 2.05 | Token: 0x84 239 | | | Observe: 217362 240 | | | Payload: "299.7 K" 241 | | | 242 .... .... 243 |<------------+ Code: 2.05 (Content) 244 | | 2.05 | Token: 0x83 245 | | | Observe: 217363 246 | | | Payload: "299.7 K" 247 | | | 248 |<------------+ Code: 2.05 (Content) 249 | | 2.05 | Token: 0x84 250 | | | Observe: 217363 251 | | | Payload: "299.7 K" 252 .... .... 254 Figure 3: Amplification attack using observe, registering the 255 same client several times, and requesting notifications at least 256 10 times every second 258 2.3. Amplification Attacks using Group Requests 260 An amplification attack using a group request is illustrated in 261 Figure 4. The group request is sent over multicast or broadcast and 262 in this case a single request results in m responses from m different 263 servers. If each response is c times larger than the request, the 264 amplification factor is c * m. Note that the servers usually do not 265 know the variable m. 267 Client Foe Server 268 | | | 269 | +----->| Code: 0.01 (GET) 270 | | GET | Token: 0x69 271 | | | Uri-Path: 272 | | | 273 |<------------+ Code: 2.05 (Content) 274 | | 2.05 | Token: 0x69 275 | | | Payload: { 1721 : { ... 276 | | | 277 |<------------+ Code: 2.05 (Content) 278 | | 2.05 | Token: 0x69 279 | | | Payload: { 1721 : { ... 280 | | | 281 .... .... 283 Figure 4: Amplification attack using multicast 285 An amplification attack using a multicast request and observe is 286 illustrated in Figure 5. In this case a single request results in n 287 responses each from m different servers giving a total of n * m 288 responses. If each response is c times larger than the request, the 289 amplification factor is c * n * m. 291 Client Foe Server 292 | | | 293 | +----->| Code: 0.01 (GET) 294 | | GET | Token: 0x44 295 | | | Observe: 0 296 | | | Uri-Path: temperature 297 | | | Uri-Query: pmax="0.1" 298 | | | 299 |<------------+ Code: 2.05 (Content) 300 | | 2.05 | Token: 0x44 301 | | | Observe: 217 302 | | | Payload: "301.2 K" 303 | | | 304 |<------------+ Code: 2.05 (Content) 305 | | 2.05 | Token: 0x44 306 | | | Observe: 363 307 | | | Payload: "293.4 K" 308 | | | 309 .... .... 310 |<------------+ Code: 2.05 (Content) 311 | | 2.05 | Token: 0x44 312 | | | Observe: 218 313 | | | Payload: "301.2 K" 314 | | | 315 |<------------+ Code: 2.05 (Content) 316 | | 2.05 | Token: 0x44 317 | | | Observe: 364 318 | | | Payload: "293.4 K" 319 | | | 320 .... .... 322 Figure 5: Amplification attack using multicast and observe 324 2.4. MITM Amplification Attacks 326 TLS and DTLS without Connection ID [I-D.ietf-tls-dtls-connection-id] 327 validate the IP address and port of the other peer, binds them to the 328 connection, and do not allow them to change. DTLS with Connection ID 329 allows the IP address and port to change at any time. As the source 330 address is not protected, an MITM attacker can change the address. 331 Note that an MITM attacker is a more capable attacker then an 332 attacker just spoofing the source address. It can be discussed if 333 and how much such an attack is reasonable for DDoS, but DTLS 1.3 334 states that "This attack is of concern when there is a large 335 asymmetry of request/response message sizes." [I-D.ietf-tls-dtls13]. 337 DTLS 1.2 with Connection ID [I-D.ietf-tls-dtls-connection-id] 338 requires that "the receiver MUST NOT replace the address" unless 339 "there is a strategy for ensuring that the new peer address is able 340 to receive and process DTLS records" but does not give more details 341 than that. It seems like the receiver can start using the new peer 342 address and test that it is able to receive and process DTLS records 343 at some later point. DTLS 1.3 with Connection ID requires that 344 "implementations MUST NOT update the address" unless "they first 345 perform some reachability test" but does not give more details than 346 that. OSCORE [RFC8613] does not discuss address updates, but it can 347 be assumed that most servers send responses to the address it 348 received the request from without any reachability test. A 349 difference between (D)TLS and OSCORE is that in DTLS the updated 350 address is used for all future records, while in OSCORE a new address 351 is only used for responses to a specific request. 353 An MITM amplification attack updating the client's source address in 354 an observe registration is illustrated in Figure 6. This attack is 355 possible in OSCORE and DTLS with Connection ID. The server will send 356 notifications to the Victim until it at some unspecified point 357 requires an acknowledgement [RFC7641]. In DTLS 1.2 the reachability 358 test might be done at a later point. In OSCORE a reachability test 359 is likely not done. 361 Client Victim Foe Server 362 | | | | 363 +------------>S----->| Code: 0.01 (GET) 364 | GET | | | Observe: 0 365 | | | | Uri-Path: humidity 366 | | | | 367 |<------------D<-----+ Reachability test (DTLS) 368 +------------>S----->| 369 | | | | 370 .... .... .... 371 | |<------------+ Code: 2.05 (Content) 372 | | | 2.05 | Observe: 263712 373 | | | | Payload: "68 %" 374 | | | | 375 | |<------------+ Code: 2.05 (Content) 376 | | | 2.05 | Observe: 263713 377 | | | | Payload: "69 %" 378 .... .... .... 380 Figure 6: MITM Amplification attack by updating the client's 381 source address in a observe registration request 383 Where 'S' means the MITM attacker is changing the source address of 384 the message and 'D' means the MITM attacker is changing the 385 destination address of the message. 387 An MITM amplification attack updating the server's source address is 388 illustrated in Figure 7. This attack is possible in DTLS with 389 Connection ID. In DTLS 1.2 the reachability test might be done at a 390 later point. 392 Client Foe Victim Server 393 | | | | 394 +------------------->| Code: 0.01 (POST) 395 | POST | | | Uri-Path: video/ 396 | | | | 397 |<-----S<------------| Code: 2.01 (Created) 398 | | | 2.01 | 399 | | | | 400 +----->D------------>| Reachability test (DTLS) 401 |<-----S<------------+ 402 | | | | 403 .... .... .... 404 +------------>| | Code: 0.01 (POST) 405 | POST | | | Uri-Path: video/ 406 | | | | Payload: survailance_1139.hevc 407 | | | | 408 +------------>| | Code: 0.01 (POST) 409 | POST | | | Uri-Path: video/ 410 | | | | Payload: survailance_1140.hevc 411 .... .... .... 413 Figure 7: MITM Amplification attack by updating the server's 414 source address in a response 416 3. Summary 418 CoAP has always considered amplification attacks, but most of the 419 requirements in [RFC7252], [RFC7641], 420 [I-D.ietf-core-echo-request-tag], and [I-D.ietf-core-groupcomm-bis] 421 are "SHOULD" instead of "MUST", it is undefined what a "large 422 amplification factor" is, [RFC7641] does not specify how many 423 notifications that can be sent before a potentially spoofable 424 acknowledgement must be sent, and in several cases the "SHOULD" level 425 is further softened by "If possible" and "generally". 426 [I-D.ietf-core-conditional-attributes] does not have any 427 amplification attack considerations. 429 QUIC [RFC9000] mandates that "an endpoint MUST limit the amount of 430 data it sends to the unvalidated address to three times the amount of 431 data received from that address" without any exceptions. This 432 approach should be seen as current best practice. 434 While it is clear when a QUIC implementation violates the requirement 435 in [RFC9000], it is not clear when a CoAP implementation violates the 436 requirement in [RFC7252], [RFC7641], 437 [I-D.ietf-core-echo-request-tag], and [I-D.ietf-core-groupcomm-bis]. 439 In CoAP, an address can be validated with a security protocol or by 440 using the Echo Option [I-D.ietf-core-echo-request-tag]. Restricting 441 the bandwidth per server is not enough as the number of servers the 442 attacker can use is typically unknown. For multicast requests, anti- 443 amplification limits and the Echo Option do not really work unless 444 the number of servers sending responses is known. Even if the 445 responses have the same size as the request, the amplification factor 446 from m servers is m, where m is typically unknown. While DoS attacks 447 from CoAP servers accessible over the Internet pose the largest 448 threat, an attacker on a local network (e.g, a compromised node) 449 might use local CoAP servers to attack targets on the Internet or on 450 the local network. 452 4. Security Considerations 454 The whole document can be seen as security considerations for CoAP. 456 5. IANA Considerations 458 This document has no actions for IANA. 460 6. Informative References 462 [DDoS-2019] 463 "DDoS Attacks 2019: A look back at the Developments over 464 the Year", Link11 , December 2019, 465 . 469 [DDoS-2021] 470 "Quarterly DDoS and Application Attack Report", Radware , 471 October 2021, 472 . 474 [DDoS-FBI] "Private Industry Notification", FBI Cyber Division , July 475 2020, . 478 [DDoS-Infra] 479 "Critical Infrastructure Under Attack", Dark Reading , 480 November 2021, . 484 [DDoS-ZDNET] 485 "The CoAP protocol is the next big thing for DDoS 486 attacks", ZDNet , December 2018, 487 . 490 [I-D.ietf-core-conditional-attributes] 491 Koster, M., Soloway, A., and B. Silverajan, "Conditional 492 Attributes for Constrained RESTful Environments", Work in 493 Progress, Internet-Draft, draft-ietf-core-conditional- 494 attributes-01, 13 January 2022, 495 . 498 [I-D.ietf-core-echo-request-tag] 499 Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo, 500 Request-Tag, and Token Processing", Work in Progress, 501 Internet-Draft, draft-ietf-core-echo-request-tag-14, 4 502 October 2021, . 505 [I-D.ietf-core-groupcomm-bis] 506 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 507 for the Constrained Application Protocol (CoAP)", Work in 508 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 509 05, 25 October 2021, . 512 [I-D.ietf-core-oscore-groupcomm] 513 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 514 and J. Park, "Group OSCORE - Secure Group Communication 515 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 516 core-oscore-groupcomm-13, 25 October 2021, 517 . 520 [I-D.ietf-lake-edhoc] 521 Selander, G., Mattsson, J. P., and F. Palombini, 522 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 523 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 524 October 2021, . 527 [I-D.ietf-tls-dtls-connection-id] 528 Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, 529 "Connection Identifiers for DTLS 1.2", Work in Progress, 530 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22 531 June 2021, . 534 [I-D.ietf-tls-dtls13] 535 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 536 Datagram Transport Layer Security (DTLS) Protocol Version 537 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 538 dtls13-43, 30 April 2021, 539 . 542 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 543 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 544 January 2012, . 546 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 547 Application Protocol (CoAP)", RFC 7252, 548 DOI 10.17487/RFC7252, June 2014, 549 . 551 [RFC7641] Hartke, K., "Observing Resources in the Constrained 552 Application Protocol (CoAP)", RFC 7641, 553 DOI 10.17487/RFC7641, September 2015, 554 . 556 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 557 RFC 8152, DOI 10.17487/RFC8152, July 2017, 558 . 560 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 561 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 562 Application Protocol) over TCP, TLS, and WebSockets", 563 RFC 8323, DOI 10.17487/RFC8323, February 2018, 564 . 566 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 567 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 568 . 570 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 571 "Object Security for Constrained RESTful Environments 572 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 573 . 575 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 576 Multiplexed and Secure Transport", RFC 9000, 577 DOI 10.17487/RFC9000, May 2021, 578 . 580 Acknowledgements 582 The authors would like to thank Carsten Bormann, Klaus Hartke, Jaime 583 Jiménez, Ari Keränen, Matthias Kovatsch, Achim Kraus, Sandeep Kumar, 584 and András Méhes for their valuable comments and feedback. 586 Authors' Addresses 588 John Preuß Mattsson 589 Ericsson AB 590 SE-164 80 Stockholm 591 Sweden 593 Email: john.mattsson@ericsson.com 595 Göran Selander 596 Ericsson AB 597 SE-164 80 Stockholm 598 Sweden 600 Email: goran.selander@ericsson.com 602 Christian Amsüss 603 Energy Harvesting Solutions 605 Email: c.amsuess@energyharvesting.at