idnits 2.17.1 draft-tiloca-tls-dos-handshake-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2017) is 2371 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-01 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-11 -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group M. Tiloca 3 Internet-Draft L. Seitz 4 Intended status: Standards Track RISE SICS AB 5 Expires: May 1, 2018 M. Hoeve 6 ENCS 7 O. Bergmann 8 Universitaet Bremen TZI 9 October 28, 2017 11 Extension for protecting (D)TLS handshakes against Denial of Service 12 draft-tiloca-tls-dos-handshake-01 14 Abstract 16 This document describes an extension for TLS and DTLS to protect the 17 server from Denial of Service attacks against the handshake protocol, 18 carried out by an on-path adversary. The extension includes a nonce 19 and a Message Authentication Code (MAC) over that nonce, encoded as a 20 Handshake Token that a Trust Anchor entity computes and provides to 21 the client. The server registered at the Trust Anchor verifies the 22 MAC to determine whether continuing or aborting the handshake. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 1, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. DoS Protection Extension . . . . . . . . . . . . . . . . . . 4 61 2.1. Extension Type . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Extension Data . . . . . . . . . . . . . . . . . . . . . 4 63 3. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Client to Trust Anchor . . . . . . . . . . . . . . . . . . . 6 65 5. Client to Server . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Server Processing . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Replay Protection . . . . . . . . . . . . . . . . . . . . . . 8 68 8. Session Resumption . . . . . . . . . . . . . . . . . . . . . 9 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 9.1. Security Effectiveness . . . . . . . . . . . . . . . . . 10 71 9.2. Renewal of Long-Term Key K_M . . . . . . . . . . . . . . 11 72 9.3. Rate Limit to Nonce Release . . . . . . . . . . . . . . . 12 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 12.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 Servers running TLS [RFC5246][I-D.ietf-tls-tls13] and DTLS 83 [RFC6347][I-D.ietf-tls-dtls13] are vulnerable to Denial of Service 84 (DoS) attacks during the very first step of the handshake protocol. 85 That is, an adversary can repeatedly send ClientHello messages to the 86 server and induce it to perform computations and execute handshakes, 87 before stopping handshake executions and make the server hold state 88 open. 90 DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 provide the optional 91 Cookie exchange as possible solution to mitigate this DoS attack. 92 This mechanism is specifically oriented towards adversaries that are 93 not on-path. That is, the Cookie exchange makes the attack more 94 complicated to mount. However, a well determined and resourceful on- 95 path adversary, able to spoof valid IP addresses, can still 96 successfully perform the DoS attack, by intercepting the possible 97 server response including the Cookie and then echoing it in the 98 second ClientHello. This is in particular possible if the handshake 99 does not use Pre-Shared Key exchange modes. 101 More specifically, the handshake protocol is exposed to DoS attacks 102 mounted by an on-path adversary, ranging minimally from a man-on-the- 103 side (i.e. able to read and inject traffic, but not block) to 104 maximally a full active adversary (i.e. able also to block traffic). 106 Depending on the specific protocol version and the key establishment 107 mode used in the handshake, the attack impact can range from a single 108 reply triggered by invalid ClientHello messages, to the server 109 performing advanced handshake steps with consequent setup of invalid 110 half-open sessions. Especially if performed in a large-scale and 111 distributed manner, this attack can thwart performance and service 112 availability of (D)TLS servers. Moreover, the attack can be 113 particularly effective in application scenarios where servers are 114 resource-constrained devices running DTLS over low-power, low 115 bandwidth and lossy networks. 117 This specification describes a "dos_protection" extension for TLS and 118 DTLS, included into ClientHello messages in order to mark them as 119 valid and neutralize the DoS attacks mentioned above. In essence, 120 the "dos_protection" extension includes a Handshake Token encoding a 121 nonce and a Message Authentication Code (MAC) computed over that 122 nonce. Upon receiving the ClientHello message, the server checks the 123 MAC conveyed in the Handshake Token, and determines whether to either 124 continue the handshake or to immediately abort it. 126 The proposed method relies on a Trust Anchor (TA) entity, which is in 127 a trust relation with the server, and authorizes the client to 128 establish a secure session with the server. In particular, the Trust 129 Anchor computes the MAC encoded in the Handshake Token, before 130 providing the latter to the client. 132 1.1. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119][RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 Readers are expected to be familiar with terms and concepts related 141 to TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347], as well as to TLS 1.3 142 [I-D.ietf-tls-tls13] and DTLS 1.3 [I-D.ietf-tls-dtls13], with 143 particular reference to their respective handshake protocol. 145 This document refers also to the following terminology. 147 o Trust Anchor (TA): a trusted third party in a trust relation with 148 the (D)TLS server. 150 o Master Key (K_M): a long-term symmetric key shared between the 151 Trust Anchor and the server. 153 o Handshake Token (T): piece of information provided by the Trust 154 Anchor to a client intending to start a handshake with the server. 155 The Handshake Token is opaque to the client, i.e. the semantics of 156 the Handshake Token are intelligible only to the Trust Anchor and 157 the server. 159 o Nonce (N): an unsigned integer value used by the Trust Anchor to 160 produce a fresh Handshake Token. The Trust Anchor maintains a 161 pairwise counter separately for each associated server, in order 162 to produce Nonce values. 164 2. DoS Protection Extension 166 2.1. Extension Type 168 This specification extends the ExtensionType enum as follows: 170 enum { 171 ..., 172 dos_protection(TBD), 173 (65535) 174 } ExtensionType; 176 2.2. Extension Data 178 The "extension_data" field of the "dos_protection" extension contains 179 the following information: 181 struct { 182 opaque handshake_token; 183 } extension_data_content; 185 The "handshake_token" field is intended to include the Handshake 186 Token generated by the Trust Anchor. The Handshake Token encodes a 187 nonce and a Message Authentication Code (MAC) computed over the 188 nonce. 190 3. Protocol overview 192 Before becoming fully operational, the server S registers at the TA 193 through a secure communication channel or other out-of-band means. A 194 server is registered at one TA only, while the same TA can be 195 associated to multiple servers. 197 For each registered server S, the TA and S maintain a pairwise 198 counter z_S, associated to that server and encoded as an unsigned 199 integer. Upon S's registration, S and the TA initialize z_S to 0 and 200 establish a long-term symmetric key K_M. The specific means to 201 establish K_M are out of the scope of this specification. 203 The rest of this document refers to H as a hash function and to an 204 HMAC [RFC2104] relying on H. The TA and the server MUST support the 205 hash function SHA-256. 207 Figure 1 shows the messages exchanged between the client (C), the 208 Trust Anchor (TA) and the server (S). 210 C TA S 211 | | | 212 | | { Shared key K_M } | 213 | | | 214 | --- Request handshake with S ---> | | 215 (1) | | | 216 | <------- Handshake Token -------- | | 217 | | | 218 --- | | | 219 | | 220 | ClientHello with "dos_protection" extension | 221 (2) | -----------------------------------------------------> | 222 | Including the Handshake Token | 223 | | 224 --- | | | 225 | | | 226 | | 227 (3) | [<-------------- Next handshake steps -------------->] | 228 | | 229 | | | 231 Figure 1: Protocol Overview 233 Step (1) concerns a client C that intends to start a (D)TLS session 234 with the server S. That is, C contacts the TA and specifies its 235 intention to start a (D)TLS handshake with S. The client C can rely 236 on services such as [I-D.ietf-core-resource-directory] to know what 237 is the specific TA associated to S. All communications between C and 238 the TA MUST be secured, ensuring integrity, source authentication, 239 confidentiality and replay protection of exchanged messages. The 240 specific means to secure communications between C and the TA are out 241 of the scope of this specification. 243 The TA MUST verify that C is authorized to establish a (D)TLS session 244 with S. To this end, the TA can directly authorize the client, or 245 expect the client to upload authorization evidence previously 246 obtained from a trusted entity. Compared with models based on 247 proxies, this approach does not require particular adaptations to the 248 communication between clients and servers. The specific 249 authorization process of clients is out of the scope of this 250 specification. 252 In case of successful authorization, the TA provides C with a fresh 253 Handshake Token, which encodes a nonce as well as a Message 254 Authentication Code (MAC) computed over the nonce using the key K_M. 255 The Handshake Token is opaque to the client. 257 During Step (2), C prepares the ClientHello message addressed to S, 258 including the "dos_protection" extension defined in Section 2. In 259 particular, the extension includes the Handshake Token received by 260 the TA, as content of the field "handshake_token". Then, C sends the 261 ClientHello message to S. The overall content and format of the 262 ClientHello message depend on the specific version of (D)TLS. 264 Upon receiving the ClientHello message, the server S retrieves the 265 Handshake Token from the "dos_protection" extension. Then, S relies 266 on the nonce included in the Handshake Token to check that the 267 ClientHello message is not a replay. After that, S uses the key K_M 268 to recompute the MAC, and checks it against the MAC encoded in the 269 received Handshake Token. 271 In case the ClientHello message is fresh and the MAC is valid, S 272 continues to Step (3), i.e., it proceeds with the handshake with C. 273 Otherwise, S discards the ClientHello message and aborts the 274 handshake. 276 4. Client to Trust Anchor 278 The client C requests from the TA an authorization to open a new 279 (D)TLS session with S. That is, this step does not take place if C 280 intends to resume a (D)TLS session previously established with S. 281 Considerations about session resumption are discussed in Section 8. 283 In case of successful authorization, the TA selects the nonce N as 284 the current value of the pairwise counter z_S associated to S. Then, 285 the TA performs the following actions. 287 1. It sets the variable token_nonce to the nonce N. 289 2. It computes a MAC as the output of HMAC(K_M, H(token_nonce)). 291 3. It builds a Handshake Token including token_nonce and the MAC. 293 After that, the TA provides the Handshake Token to C, and increments 294 the counter z_S by 1. 296 The TA handles a wrap-around of the counter z_S by renewing the 297 Master Key K_M as described in Section 9.2. 299 5. Client to Server 301 This section considers a client C intending to establish a new (D)TLS 302 session with S. Considerations about session resumption are 303 discussed in Section 8. 305 When preparing the ClientHello message, the client C proceeds as 306 follows. 308 1. It builds the "dos_protection" extension defined in Section 2. 310 2. It includes the Handshake Token received from the TA in the 311 "handshake_token" field of the "dos_protection" extension. 313 3. It includes the "dos_protection" extension into the ClientHello 314 message, consistently with what is mandated and recommended by 315 the specific version of (D)TLS. 317 Once the ClientHello message has been completely prepared, C 318 transmits it to S. Note that C retransmits exactly the same 319 "dos_protection" extension from this first ClientHello message, in 320 case it sends a second ClientHello message as a reply to a 321 HelloVerifyRequest in DTLS 1.2 or a HelloRetryRequest in (D)TLS 1.3. 323 6. Server Processing 325 This section considers a server S receiving a ClientHello message 326 from C for initiating a new (D)TLS session. Considerations on 327 session resumption are discussed in Section 8. 329 A server MAY require clients to send a valid "dos_protection" 330 extension. A server requiring this MUST respond to a ClientHello 331 lacking a "dos_protection" extension by terminating the handshake, 332 with a "missing_extension" alert if the client has shown support for 333 (D)TLS 1.3, or a "handshake_failure" alert otherwise. 335 Upon receiving the first ClientHello message from C, the server S 336 retrieves the Handshake Token from the "handshake_token" field of the 337 "dos_protection" extension. 339 Then, the server S MUST check that the ClientHello message is not a 340 replay. Section 7 of this specification describes a possible method 341 to perform the anti-replay check, based on the nonce encoded in the 342 Handhshake Token. If the ClientHello message is found to be not 343 fresh, then S discards it and terminates the handshake with a 344 "handshake_failure" alert. 346 If the ClientHello message is found to be fresh, then S performs the 347 following actions. 349 1. It retrieves token_nonce from the Handshake Token. 351 2. It computes a MAC as the output of HMAC(K_M, H(token_nonce)). 353 If the computed MAC differs from the MAC encoded in the Handshake 354 Token, S discards the ClientHello message and terminates the 355 handshake with a "handshake_failure" alert. Otherwise, S continues 356 performing the handshake with C. 358 7. Replay Protection 360 This section describes a possible method to perform anti-replay 361 checks on received ClientHello messages, based on the nonce encoded 362 in the Handshake Token as token_nonce. 364 The server S maintains a sliding window W of size A, as a pair {w, 365 w_b}, where w is an A-bit vector and w_b indicates the current left 366 bound of W. That is, w_b indicates the lowest value that S can 367 accept as the nonce N encoded in the Handshake Token as token_nonce. 368 Upon startup, S sets w_b to 0 and all bits in w to 0. 370 Upon receiving a ClientHello message for establishing a new (D)TLS 371 session, the server S considers the nonce N encoded in the Handshake 372 Token as token_nonce, and performs the following checks. As an 373 example, the following considers a 32-bit nonce N. 375 o If N < w_b, then S discards the ClientHello message and terminates 376 the handshake. 378 o If w_b <= N < min(w_b + A, 2^32), then S defines i = (N - w_b), 379 and checks the i-th bit of vector w. If such bit is set to 1, 380 i.e. the same nonce N has been already used, then S discards the 381 ClientHello message and terminates the handshake. Instead, if 382 such bit is set to 0, then S proceeds with processing the 383 "dos_protection" extension as described in Section 6. 385 o If (w_b + A) <= N < 2^32, then S proceeds with processing the 386 "dos_protection" extension as described in Section 6. 388 During this handshake execution, S discards any possible first 389 ClientHello message including the same nonce N encoded in the 390 Handshake Token as token_nonce. 392 Once the handshake has been successfully completed, S checks whether 393 the condition N >= w_b is still valid. In such a case, S updates the 394 window W as follows. 396 o If w_b <= N < min(w_b + A, 2^32), then S defines i = (N - w_b) and 397 sets the i-th bit of vector w to 1, so marking N as used. 398 Instead, 400 o if (w_b + A) <= N < 2^32, then S defines w* = (N - A + 1) and 401 updates vector w as w = w >> (w* - w_b), where '>>' is the 402 unsigned right bit shift operator. After that, S updates w_b as 403 w_b = w*. Finally, S defines i = (N - w_b) and sets the i-th bit 404 of vector w to 1, so marking N as used. 406 The window size A should be determined based on the expected 407 frequency of new session establishments on the server S. Evidently, 408 the larger the window, the more accurate is the replay protection, 409 but the greater the memory overhead on the server side. 411 8. Session Resumption 413 In case a client C sends a ClientHello message asking to resume a 414 session, the server S relies on the existing association with C and 415 hence does not need a further assertion of client's validity from the 416 TA. In addition, S can rely on the Client Hello Recording mechanism 417 described in Section 8 of [I-D.ietf-tls-tls13], in order to perform 418 anti-replay checks on ClientHello messages asking for session 419 resumption. 421 As a consequence, the "dos_protection" extension defined in Section 2 422 is not strictly necessary in ClientHello messages sent for session 423 resumption. 425 However, Section 7.4.1.4 of [RFC5246] states that a client asking for 426 session resumption SHOULD send the same extensions as it would if it 427 was not attempting resumption. At the same time, it states that most 428 extensions are relevant only when a new session is initiated, and 429 hence the server would not process them in case of session 430 resumption. 432 In accordance with such guidelines, a server S can possibly instruct 433 the TA to also provide requesting clients with a small number R of 434 additional Resumption Tokens. 436 In order to compute each of the Resumption Tokens for a same request 437 from a given client, the TA MUST use the same nonce value N used to 438 compute the Handshake Token (see Section 4). In particular, the TA 439 computes the i-th Resumption Token, 0 <= i < R, as follows. 441 1. It sets the variable token_nonce to (N + i), where '+' is the 442 concatenate operator. 444 2. It computes a MAC as the output of HMAC(K_M, H(token_nonce)). 446 3. It builds the i-th Resumption Token including token_nonce and the 447 MAC. 449 Finally, the TA provides the requesting client with the Handshake 450 Token and the additional Resumption Tokens. The client MUST use the 451 Handshake Token during a handshake with S for session initiation, as 452 described in Section 5. The client MUST use the i-th Resumption 453 Token upon attempting the i-th resumption of that session. After it 454 has used all the Resumption Tokens received from the TA, the client 455 MUST assume that S does not support further resumptions of the same 456 session. 458 Upon receiving a ClientHello message from C asking to resume a 459 session, the server S verifies the MAC encoded in the Resumption 460 Token as described in Section 6. However, S does not rely on the 461 "dos_protection" extension and the token_nonce in the Resumption 462 Token to perform an anti-replay check. 464 Further details about session resumption are defined in the (D)TLS 465 specifications of the different respective versions. 467 9. Security Considerations 469 This specification does not change the intended security properties 470 of TLS and DTLS. Additional security aspects are discussed below. 472 9.1. Security Effectiveness 474 The MAC encoded in the "dos_protection" extension as part of the 475 Handshake Token is computed only over the 'token_nonce' part of the 476 same Handshake Token. That is, a server S can actually assert the 477 validity and freshness of the Handshake Token only, rather than of 478 the whole ClientHello message. 480 As a consequence, an on-path adversary can intercept ClientHello 481 messages sent by legitimate clients, retrieve the "dos_protection" 482 extension, and then use it inside forged ClientHello messages 483 injected and addressed to the server. However, this practically 484 displays negligible consequences in terms of additional impact on the 485 server, as discussed in the following. 487 On one hand, a man-on-the-side adversary, namely able to intercept 488 and inject traffic but not block, can, with reasonable effort, 489 exploit the limitation above in order to induce the server to 490 negotiate more expensive cipher suites, which is fair to consider as 491 a weak attack achievement. Furthermore, the injection of such forged 492 ClientHello messages including a stolen "dos_protection" extension is 493 anyway rate limited by the number of legitimate clients and the 494 frequency of their handshake executions. 496 On the other hand, a full active adversary, namely able to also block 497 traffic, would not even bother to inject forged ClientHello messages 498 including a stolen "dos_protection" extension. In fact, (s)he can 499 more easily let the server process handshake messages from legitimate 500 clients during handhshake early phases, and later on block specific 501 client messages during handshake advanced phases, so leaving the 502 server with several half-open sessions and open states. Again, this 503 is anyway rate limited by the number of legitimate clients and the 504 frequency of their handshake executions. 506 9.2. Renewal of Long-Term Key K_M 508 While it can practically take a long amount of time, the pairwise 509 counter z_S maintained by the TA and associated to S eventually wraps 510 around. When this happens, the TA MUST revoke the key K_M shared 511 with S, in order to not reuse {K_M, N} pairs when building Handshake 512 Tokens for requesting clients. 514 In particular, when the counter z_S wraps-around, the TA MUST perform 515 the following actions. 517 1. It stops accepting requests related to S from clients. 519 2. It securely generates a new long-term key K_M and securely 520 provides it to S. 522 3. It resumes serving requests related to S from clients, using the 523 new K_M to compute MACs when building Handshake Tokens. 525 9.3. Rate Limit to Nonce Release 527 It is RECOMMENDED that the TA does not release Handshake Tokens to 528 clients beyond a maximum rate. This prevents a client with 529 legitimate credentials from quickly consuming the nonce space 530 associated to S, and thus making the TA unable to serve other 531 clients. 533 10. IANA Considerations 535 IANA is requested to allocate an entry to the existing TLS 536 "ExtensionType" registry defined in [RFC5246] and originally created 537 in [RFC4366], for dos_protection (TBD) defined in this document. 539 11. Acknowledgments 541 The authors are sincerely thankful to Santiago Aragon, Rolf Blom and 542 Eric Rescorla for their comments and feedback. 544 The work on this document has been partly supported by the EU FP7 545 project SEGRID (Grant Agreement no. 607109) and the EIT-Digital High 546 Impact Initiative ACTIVE. 548 12. References 550 12.1. Normative References 552 [I-D.ietf-tls-dtls13] 553 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 554 Datagram Transport Layer Security (DTLS) Protocol Version 555 1.3", draft-ietf-tls-dtls13-01 (work in progress), July 556 2017. 558 [I-D.ietf-tls-tls13] 559 Rescorla, E., "The Transport Layer Security (TLS) Protocol 560 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 561 July 2017. 563 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 564 Hashing for Message Authentication", RFC 2104, 565 DOI 10.17487/RFC2104, February 1997, . 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, 570 DOI 10.17487/RFC2119, March 1997, . 573 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 574 (TLS) Protocol Version 1.2", RFC 5246, 575 DOI 10.17487/RFC5246, August 2008, . 578 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 579 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 580 January 2012, . 582 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 583 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 584 May 2017, . 586 12.2. Informative References 588 [I-D.ietf-core-resource-directory] 589 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 590 Amsuess, "CoRE Resource Directory", draft-ietf-core- 591 resource-directory-11 (work in progress), July 2017. 593 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 594 and T. Wright, "Transport Layer Security (TLS) 595 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 596 . 598 Authors' Addresses 600 Marco Tiloca 601 RISE SICS AB 602 Isafjordsgatan 22 603 Kista SE-164 29 604 Sweden 606 Phone: +46 70 604 65 01 607 Email: marco.tiloca@ri.se 609 Ludwig Seitz 610 RISE SICS AB 611 Scheelevaegen 17 612 Lund SE-223 70 613 Sweden 615 Phone: +46 70 349 92 51 616 Email: ludwig.seitz@ri.se 617 Maarten Hoeve 618 ENCS 619 Regulusweg 5 620 The Hague 2516 AC 621 The Netherlands 623 Phone: +31 62 015 75 51 624 Email: maarten.hoeve@encs.eu 626 Olaf Bergmann 627 Universitaet Bremen TZI 628 Postfach 330440 629 Bremen D-28359 630 Germany 632 Phone: +49 421 218 63904 633 Email: bergmann@tzi.org