idnits 2.17.1 draft-tiloca-tls-dos-handshake-02.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 (March 05, 2018) is 2237 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-22 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-24 ** 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-12 -- 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: September 6, 2018 M. Hoeve 6 ENCS 7 O. Bergmann 8 Universitaet Bremen TZI 9 March 05, 2018 11 Extension for protecting (D)TLS handshakes against Denial of Service 12 draft-tiloca-tls-dos-handshake-02 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 https://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 September 6, 2018. 41 Copyright Notice 43 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Replay Protection . . . . . . . . . . . . . . . . . . . . . . 8 68 8. Session Resumption . . . . . . . . . . . . . . . . . . . . . 10 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 9.1. Security Effectiveness . . . . . . . . . . . . . . . . . 11 71 9.2. Trust Anchor as Target . . . . . . . . . . . . . . . . . 12 72 9.3. Renewal of Long-Term Key K_M . . . . . . . . . . . . . . 12 73 9.4. Rate Limit to Nonce Release . . . . . . . . . . . . . . . 13 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 12.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Servers running TLS [RFC5246][I-D.ietf-tls-tls13] and DTLS 84 [RFC6347][I-D.ietf-tls-dtls13] are vulnerable to Denial of Service 85 (DoS) attacks during the very first step of the handshake protocol. 86 That is, an adversary can repeatedly send ClientHello messages to the 87 server and induce it to perform computations and execute handshakes, 88 before stopping handshake executions and make the server hold state 89 open. 91 DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 provide the optional 92 Cookie exchange as possible solution to mitigate this DoS attack. 93 This mechanism is specifically oriented towards adversaries that are 94 not on-path. That is, the Cookie exchange makes the attack more 95 complicated to mount. However, a well determined and resourceful on- 96 path adversary, able to spoof valid IP addresses, can still 97 successfully perform the DoS attack, by intercepting the possible 98 server response including the Cookie and then echoing it in the 99 second ClientHello. This is in particular possible if the handshake 100 does not use Pre-Shared Key exchange modes. 102 More specifically, the handshake protocol is exposed to DoS attacks 103 mounted by an on-path adversary, ranging minimally from a man-on-the- 104 side (i.e. able to read and inject traffic, but not block) to 105 maximally a full active adversary (i.e. able also to block traffic). 107 Depending on the specific protocol version and the key establishment 108 mode used in the handshake, the attack impact can range from a single 109 reply triggered by invalid ClientHello messages, to the server 110 performing advanced handshake steps with consequent setup of invalid 111 half-open sessions. Especially if performed in a large-scale and 112 distributed manner, this attack can thwart performance and service 113 availability of (D)TLS servers. Moreover, the attack can be 114 particularly effective in application scenarios where servers are 115 resource-constrained devices running DTLS over low-power, low 116 bandwidth and lossy networks. 118 This specification describes a "dos_protection" extension for TLS and 119 DTLS, included into ClientHello messages in order to mark them as 120 valid and neutralize the DoS attacks mentioned above. In essence, 121 the "dos_protection" extension includes a Handshake Token encoding a 122 nonce and a Message Authentication Code (MAC) computed over that 123 nonce. Upon receiving the ClientHello message, the server checks the 124 MAC conveyed in the Handshake Token, and determines whether to either 125 continue the handshake or to immediately abort it. 127 The proposed method relies on a Trust Anchor (TA) entity, which is in 128 a trust relation with the server, and authorizes the client to 129 establish a secure session with the server. In particular, the Trust 130 Anchor computes the MAC encoded in the Handshake Token, before 131 providing the latter to the client. 133 1.1. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119][RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 Readers are expected to be familiar with terms and concepts related 142 to TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347], as well as to TLS 1.3 143 [I-D.ietf-tls-tls13] and DTLS 1.3 [I-D.ietf-tls-dtls13], with 144 particular reference to their respective handshake protocol. 146 This document refers also to the following terminology. 148 o Trust Anchor (TA): a trusted third party with a security 149 association with the (D)TLS server. Compared to each single 150 (D)TLS server it is associated to, the Trust Anchor is usually 151 equipped with significant larger amounts of resources, especially 152 in terms of computing power and memory availability. 154 o Master Key (K_M): a long-term symmetric key shared between the 155 Trust Anchor and the server. 157 o Handshake Token (T): piece of information provided by the Trust 158 Anchor to a client intending to start a handshake with the server. 159 The Handshake Token is opaque to the client, i.e. the semantics of 160 the Handshake Token are intelligible only to the Trust Anchor and 161 the server. 163 o Nonce (N): an unsigned integer value used by the Trust Anchor to 164 produce a fresh Handshake Token. The Trust Anchor maintains a 165 pairwise counter separately for each associated server, in order 166 to produce Nonce values. 168 2. DoS Protection Extension 170 2.1. Extension Type 172 This specification extends the ExtensionType enum as follows: 174 enum { 175 ..., 176 dos_protection(TBD), 177 (65535) 178 } ExtensionType; 180 2.2. Extension Data 182 The "extension_data" field of the "dos_protection" extension contains 183 the following information: 185 struct { 186 opaque handshake_token; 187 } extension_data_content; 189 The "handshake_token" field is intended to include the Handshake 190 Token generated by the Trust Anchor. The Handshake Token encodes a 191 nonce and a Message Authentication Code (MAC) computed over the 192 nonce. 194 3. Protocol overview 196 Before becoming fully operational, the server S registers at the TA 197 through a secure communication channel or other out-of-band means. A 198 server is registered at one TA only, while the same TA can be 199 associated to multiple servers. 201 For each registered server S, the TA and S maintain a pairwise 202 counter z_S, associated to that server and encoded as an unsigned 203 integer. Upon S's registration, S and the TA initialize z_S to 0 and 204 establish a long-term symmetric key K_M. The specific means to 205 establish K_M are out of the scope of this specification. 207 The rest of this document refers to H as a hash function and to an 208 HMAC [RFC2104] relying on H. The TA and the server MUST support the 209 hash function SHA-256. 211 Figure 1 shows the messages exchanged between the client (C), the 212 Trust Anchor (TA) and the server (S). 214 C TA S 215 | | | 216 | | { Shared key K_M } | 217 | | | 218 | --- Request handshake with S ---> | | 219 (1) | | | 220 | <------- Handshake Token -------- | | 221 | | | 222 --- | | | 223 | | 224 | ClientHello with "dos_protection" extension | 225 (2) | -----------------------------------------------------> | 226 | Including the Handshake Token | 227 | | 228 --- | | | 229 | | | 230 | | 231 (3) | [<-------------- Next handshake steps -------------->] | 232 | | 233 | | | 235 Figure 1: Protocol Overview 237 Step (1) concerns a client C that intends to start a (D)TLS session 238 with the server S. That is, C contacts the TA and specifies its 239 intention to start a (D)TLS handshake with S. The client C can rely 240 on services such as [I-D.ietf-core-resource-directory] to know what 241 is the specific TA associated to S. All communications between C and 242 the TA must be secured, ensuring integrity, source authentication, 243 confidentiality and replay protection of exchanged messages. The 244 specific means to secure communications between C and the TA are out 245 of the scope of this specification. 247 The TA must verify that C is authorized to establish a (D)TLS session 248 with S. To this end, the TA can directly authorize the client, or 249 expect the client to upload authorization evidence previously 250 obtained from a trusted entity. Compared with models based on 251 proxies, this approach does not require particular adaptations to the 252 communication between clients and servers. The specific 253 authorization process of clients is out of the scope of this 254 specification. 256 In case of successful authorization, the TA provides C with a fresh 257 Handshake Token, which encodes a nonce as well as a Message 258 Authentication Code (MAC) computed over the nonce using the key K_M. 259 The Handshake Token is opaque to the client. Besides, the client 260 must consume this Handshake Token right away, and in particular 261 before asking the TA for a new Handshake Token intended for the same 262 server S. 264 During Step (2), C prepares the ClientHello message addressed to S, 265 including the "dos_protection" extension defined in Section 2. In 266 particular, the extension includes the Handshake Token received by 267 the TA, as content of the field "handshake_token". Then, C sends the 268 ClientHello message to S. The overall content and format of the 269 ClientHello message depend on the specific version of (D)TLS. 271 Upon receiving the ClientHello message, the server S retrieves the 272 Handshake Token from the "dos_protection" extension. Then, S relies 273 on the nonce included in the Handshake Token to check that the 274 ClientHello message is not a replay. After that, S uses the key K_M 275 to recompute the MAC, and checks it against the MAC encoded in the 276 received Handshake Token. 278 In case the ClientHello message is fresh and the MAC is valid, S 279 continues to Step (3), i.e., it proceeds with the handshake with C. 280 Otherwise, S discards the ClientHello message and aborts the 281 handshake. 283 4. Client to Trust Anchor 285 The client C requests from the TA an authorization to open a new 286 (D)TLS session with the server S. That is, this step does not take 287 place if C intends to resume a (D)TLS session previously established 288 with S. Considerations about session resumption are provided in 289 Section 8. 291 In case of successful authorization, the TA selects the nonce N as 292 the current value of the pairwise counter z_S associated to S. Then, 293 the TA performs the following actions. 295 1. It sets the variable token_nonce to the nonce N. 297 2. It computes a MAC as the output of HMAC(K_M, H(token_nonce)). 299 3. It builds a Handshake Token including token_nonce and the MAC. 301 After that, the TA provides the Handshake Token to C, and increments 302 the counter z_S by 1. 304 The TA handles a wrap-around of the counter z_S by renewing the 305 Master Key K_M as described in Section 9.3. 307 5. Client to Server 309 This section considers a client C intending to establish a new (D)TLS 310 session with S. Considerations about session resumption are provided 311 in Section 8. 313 Once it has received the Handshake Token from the TA, the client C 314 must consume it right away, by including it in a ClientHello message 315 addressed to the server S. In particular, the client C must consume 316 this Handshake Token before asking the TA for a new one intended for 317 the same server S. The client C considers the Handshake Token 318 consumed, and hence discards it, once received a valid ServerHello 319 message during the same handshake with the server S. 321 Furthermore, the client discards a Handshake Token also in case of 322 handshake abortion due to too many retransmissions of a same 323 ClientHello message. In such a case, the client must ask the TA for 324 a new, i.e. fresh, Handshake Token and start over a new handshake 325 with the server S. 327 When preparing the ClientHello message, the client C proceeds as 328 follows. 330 1. It builds the "dos_protection" extension defined in Section 2. 332 2. It includes the Handshake Token received from the TA in the 333 "handshake_token" field of the "dos_protection" extension. 335 3. It includes the "dos_protection" extension into the ClientHello 336 message, consistently with what is mandated and recommended by 337 the specific version of (D)TLS. 339 Once the ClientHello message has been completely prepared, C 340 transmits it to S. Note that C retransmits exactly the same 341 "dos_protection" extension from this first ClientHello message, in 342 case it sends a second ClientHello message as a reply to a 343 HelloVerifyRequest in DTLS 1.2 or a HelloRetryRequest in (D)TLS 1.3. 345 6. Server Processing 347 This section considers a server S receiving a ClientHello message 348 from C for initiating a new (D)TLS session. Considerations on 349 session resumption are provided in Section 8. 351 A server MAY require clients to send a valid "dos_protection" 352 extension. A server requiring this MUST respond to a ClientHello 353 lacking a "dos_protection" extension by terminating the handshake, 354 with a "missing_extension" alert if the client has shown support for 355 (D)TLS 1.3, or a "handshake_failure" alert otherwise. 357 Upon receiving the first ClientHello message from C, the server S 358 retrieves the Handshake Token from the "handshake_token" field of the 359 "dos_protection" extension. 361 Then, the server S MUST check that the ClientHello message is not a 362 replay. Section 7 of this specification describes a possible method 363 to perform the anti-replay check, based on the nonce encoded in the 364 Handhshake Token. If the ClientHello message is found to be not 365 fresh, then S discards it and terminates the handshake with a 366 "handshake_failure" alert. 368 If the ClientHello message is found to be fresh, then S performs the 369 following actions. 371 1. It retrieves token_nonce from the Handshake Token. 373 2. It computes a MAC as the output of HMAC(K_M, H(token_nonce)). 375 If the computed MAC differs from the MAC encoded in the Handshake 376 Token, S discards the ClientHello message and terminates the 377 handshake with a "handshake_failure" alert. Otherwise, S continues 378 performing the handshake with C. 380 7. Replay Protection 382 This section describes a possible method to perform anti-replay 383 checks on received ClientHello messages, based on the nonce encoded 384 in the Handshake Token as token_nonce. 386 The server S maintains a sliding window W of size A, as a pair {w, 387 w_b}, where w is an A-bit vector and w_b indicates the current left 388 bound of W. That is, w_b indicates the lowest value that S can 389 accept as the nonce N encoded in the Handshake Token as token_nonce. 390 Upon startup, S sets w_b to 0 and all bits in w to 0. 392 Upon receiving a ClientHello message for establishing a new (D)TLS 393 session, the server S considers the nonce N encoded in the Handshake 394 Token as token_nonce, and performs the following checks. As an 395 example, the following considers a 32-bit nonce N. 397 o If N < w_b, then S discards the ClientHello message and terminates 398 the handshake. 400 o If w_b <= N < min(w_b + A, 2^32), then S defines i = (N - w_b), 401 and checks the i-th bit of vector w. If such bit is set to 1, 402 i.e. the same nonce N has been already used, then S discards the 403 ClientHello message and terminates the handshake. Instead, if 404 such bit is set to 0, then S proceeds with processing the 405 "dos_protection" extension as described in Section 6. 407 o If (w_b + A) <= N < 2^32, then S proceeds with processing the 408 "dos_protection" extension as described in Section 6. 410 During this handshake execution, S discards any possible first 411 ClientHello message including the same nonce N encoded in the 412 Handshake Token as token_nonce. 414 Once the handshake has been successfully completed, S checks whether 415 the condition N >= w_b is still valid. In such a case, S updates the 416 window W as follows. 418 o If w_b <= N < min(w_b + A, 2^32), then S defines i = (N - w_b) and 419 sets the i-th bit of vector w to 1, so marking N as used. 420 Instead, 422 o if (w_b + A) <= N < 2^32, then S defines w* = (N - A + 1) and 423 updates vector w as w = w >> (w* - w_b), where '>>' is the 424 unsigned right bit shift operator. After that, S updates w_b as 425 w_b = w*. Finally, S defines i = (N - w_b) and sets the i-th bit 426 of vector w to 1, so marking N as used. 428 The window size A should be determined based on the expected 429 frequency of new session establishments on the server S. Evidently, 430 the larger the window, the more accurate is the replay protection, 431 but the greater the memory overhead on the server side. 433 Furthermore, the window size A should take into account the time 434 required for a client to request and get a Handshake Token from the 435 TA, as well as to to deliver it to the (D)TLS server in the 436 ClientHello message. This is necessary in order to avoid that the 437 sliding window advances too fast, and hence that the (D)TLS server 438 discards such ClientHello messages as stale. 440 8. Session Resumption 442 In case a client C sends a ClientHello message asking to resume a 443 session, the server S relies on the existing association with C and 444 hence does not need a further assertion of client's validity from the 445 TA. In addition, S can rely on the Client Hello Recording mechanism 446 described in Section 8 of [I-D.ietf-tls-tls13], in order to perform 447 anti-replay checks on ClientHello messages asking for session 448 resumption. 450 As a consequence, the "dos_protection" extension defined in Section 2 451 is not strictly necessary in ClientHello messages sent for session 452 resumption. 454 However, Section 7.4.1.4 of [RFC5246] states that a client asking for 455 session resumption SHOULD send the same extensions as it would if it 456 was not attempting resumption. At the same time, it states that most 457 extensions are relevant only when a new session is initiated, and 458 hence the server would not process them in case of session 459 resumption. 461 In accordance with such guidelines, a server S can possibly instruct 462 the TA to also provide requesting clients with a small number R of 463 additional Resumption Tokens. 465 In order to compute each of the Resumption Tokens for a same request 466 from a given client, the TA MUST use the same nonce value N used to 467 compute the Handshake Token (see Section 4). In particular, the TA 468 computes the i-th Resumption Token, 0 <= i < R, as follows. 470 1. It sets the variable token_nonce to (N + i), where '+' is the 471 concatenate operator. 473 2. It computes a MAC as the output of HMAC(K_M, H(token_nonce)). 475 3. It builds the i-th Resumption Token including token_nonce and the 476 MAC. 478 Finally, the TA provides the requesting client with the Handshake 479 Token and the additional Resumption Tokens. The client MUST use the 480 Handshake Token during a handshake with S for session initiation, as 481 described in Section 5. The client MUST use the i-th Resumption 482 Token upon attempting the i-th resumption of that session. After it 483 has used all the Resumption Tokens received from the TA, the client 484 must assume that S does not support further resumptions of the same 485 session. 487 Upon receiving a ClientHello message from C asking to resume a 488 session, the server S verifies the MAC encoded in the Resumption 489 Token as described in Section 6. However, S does not rely on the 490 "dos_protection" extension and the token_nonce in the Resumption 491 Token to perform an anti-replay check. 493 Further details about session resumption are defined in the (D)TLS 494 specifications of the different respective versions. 496 9. Security Considerations 498 This specification does not change the intended security properties 499 of TLS and DTLS. Additional security aspects are discussed below. 501 9.1. Security Effectiveness 503 The MAC encoded in the "dos_protection" extension as part of the 504 Handshake Token is computed only over the 'token_nonce' part of the 505 same Handshake Token. That is, a server S can actually assert the 506 validity and freshness of the Handshake Token only, rather than of 507 the whole ClientHello message. 509 As a consequence, an on-path adversary can intercept ClientHello 510 messages sent by legitimate clients, retrieve the "dos_protection" 511 extension, and then use it inside forged ClientHello messages 512 injected and addressed to the server. However, this practically 513 displays negligible consequences in terms of additional impact on the 514 server, as discussed in the following. 516 On one hand, a man-on-the-side adversary, namely able to intercept 517 and inject traffic but not block, can, with reasonable effort, 518 exploit the limitation above in order to induce the server to 519 negotiate more expensive cipher suites, which is fair to consider as 520 a weak attack achievement. Furthermore, the injection of such forged 521 ClientHello messages including a stolen "dos_protection" extension is 522 anyway rate limited by the number of legitimate clients and the 523 frequency of their handshake executions. 525 On the other hand, a full active adversary, namely able to also block 526 traffic, would not even bother to inject forged ClientHello messages 527 including a stolen "dos_protection" extension. In fact, (s)he can 528 more easily let the server process handshake messages from legitimate 529 clients during handhshake early phases, and later on block specific 530 client messages during handshake advanced phases, so leaving the 531 server with several half-open sessions and open states. Again, this 532 is anyway rate limited by the number of legitimate clients and the 533 frequency of their handshake executions. 535 9.2. Trust Anchor as Target 537 Communications between clients and the TA may be secured by means of 538 (D)TLS, with the TA acting as server. In such a case, the TA becomes 539 also a target for the DoS attack addressed in this specification. 541 On the other hand, TAs are expected to be equipped with plentiful of 542 resources, i.e. in significant larger amounts than each of the 543 associated (D)TLS servers. That is, given a class of adversary 544 targeting a number of (D)TLS servers, the corresponding TA is 545 practically not a feasible target for that adversary. 547 Besides, while it is infeasible to expect a considerably high number 548 of (resource-contrained) (D)TLS servers to be robust against DoS by 549 construction, it is instead feasible to have relatively few deployed 550 TAs which are able to endure this attack when carried out against 551 them. This might in turn encourage an adversary to rather target a 552 TA, in order to indirectly make the (D)TLS servers unavailable to 553 serve clients. However, as discussed above, a class of adversary 554 targeting a (D)TLS server is not supposed to have sufficient 555 resources to effectively compromise the availability of the 556 corresponding TA. 558 Furthermore, a typical starting point for an adversary consists in 559 identifying the set of victim servers, as belonging to the same 560 application/administrative domain(s) or network segment(s). Hence, 561 the adversary would be motivated in targeting the TA(s) associated to 562 the (D)TLS servers in those segments. As an additional deterrent, 563 (D)TLS servers in a same segment or domain can thus be registered at 564 different TAs, in order to further reduce the feasibility and spread 565 the effectiveness of attacks rather addressed against those TAs. 567 9.3. Renewal of Long-Term Key K_M 569 While it can practically take a long amount of time, the pairwise 570 counter z_S maintained by the TA and associated to S eventually wraps 571 around. When this happens, the TA MUST revoke the key K_M shared 572 with S, in order to not reuse {K_M, N} pairs when building Handshake 573 Tokens for requesting clients. 575 In particular, when the counter z_S wraps-around, the TA MUST perform 576 the following actions. 578 1. It stops accepting requests related to S from clients. 580 2. It securely generates a new long-term key K_M and securely 581 provides it to S. 583 3. It resumes serving requests related to S from clients, using the 584 new K_M to compute MACs when building Handshake Tokens. 586 9.4. Rate Limit to Nonce Release 588 It is RECOMMENDED that the TA does not release Handshake Tokens to 589 clients beyond a maximum rate. This prevents a client with 590 legitimate credentials from quickly consuming the nonce space 591 associated to S, and thus making the TA unable to serve other 592 clients. 594 10. IANA Considerations 596 IANA is requested to allocate an entry to the existing TLS 597 "ExtensionType" registry defined in [RFC5246] and originally created 598 in [RFC4366], for dos_protection (TBD) defined in this document. 600 11. Acknowledgments 602 The authors are sincerely thankful to Santiago Aragon, Rolf Blom and 603 Eric Rescorla for their comments and feedback. 605 The work on this document has been partly supported by the EU FP7 606 project SEGRID (Grant Agreement no. 607109) and the EIT-Digital High 607 Impact Initiative ACTIVE. 609 12. References 611 12.1. Normative References 613 [I-D.ietf-tls-dtls13] 614 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 615 Datagram Transport Layer Security (DTLS) Protocol Version 616 1.3", draft-ietf-tls-dtls13-22 (work in progress), 617 November 2017. 619 [I-D.ietf-tls-tls13] 620 Rescorla, E., "The Transport Layer Security (TLS) Protocol 621 Version 1.3", draft-ietf-tls-tls13-24 (work in progress), 622 February 2018. 624 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 625 Hashing for Message Authentication", RFC 2104, 626 DOI 10.17487/RFC2104, February 1997, 627 . 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, 631 DOI 10.17487/RFC2119, March 1997, 632 . 634 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 635 (TLS) Protocol Version 1.2", RFC 5246, 636 DOI 10.17487/RFC5246, August 2008, 637 . 639 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 640 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 641 January 2012, . 643 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 644 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 645 May 2017, . 647 12.2. Informative References 649 [I-D.ietf-core-resource-directory] 650 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 651 Amsuess, "CoRE Resource Directory", draft-ietf-core- 652 resource-directory-12 (work in progress), October 2017. 654 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 655 and T. Wright, "Transport Layer Security (TLS) 656 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 657 . 659 Authors' Addresses 661 Marco Tiloca 662 RISE SICS AB 663 Isafjordsgatan 22 664 Kista SE-164 29 665 Sweden 667 Phone: +46 70 604 65 01 668 Email: marco.tiloca@ri.se 669 Ludwig Seitz 670 RISE SICS AB 671 Scheelevaegen 17 672 Lund SE-223 70 673 Sweden 675 Phone: +46 70 349 92 51 676 Email: ludwig.seitz@ri.se 678 Maarten Hoeve 679 ENCS 680 Regulusweg 5 681 The Hague 2516 AC 682 The Netherlands 684 Phone: +31 62 015 75 51 685 Email: maarten.hoeve@encs.eu 687 Olaf Bergmann 688 Universitaet Bremen TZI 689 Postfach 330440 690 Bremen D-28359 691 Germany 693 Phone: +49 421 218 63904 694 Email: bergmann@tzi.org