idnits 2.17.00 (12 Aug 2021) /tmp/idnits52412/draft-nir-tls-puzzles-00.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 (April 29, 2014) is 2937 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 139, but not defined ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4366 (ref. 'TLS-EXT') (Obsoleted by RFC 5246, RFC 6066) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Experimental April 29, 2014 5 Expires: October 31, 2014 7 Using Client Puzzles to Protect TLS Servers From Denial of Service 8 Attacks 9 draft-nir-tls-puzzles-00 11 Abstract 13 This document proposes a mechanism for mitigating denial of service 14 (DoS) and distributed denial of service (DDoS) attacks on TLS 15 servers. Attackers are limited in their ability to cause resource 16 waste on the server by requiring proof of work by the client before 17 these CPU resources are expended. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 31, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 TLS ([TLS]) is vulnerable to a simple denial of service (DoS) attack. 54 Arbitrary hosts on the Internet can begin a TLS handshake with a 55 server. The attacking clients need only generate a valid TLS 56 ClientHello and a valid-looking ClientKeyExchange, both of which 57 require very little computing resources. 59 To respond, the server has to perform some CPU-intensive operations. 60 Depending on the chosen ciphersuite, the server will need to perform 61 an RSA decryption or a Diffie-Hellman exchange plus a RSA, DSA, or 62 ECDSA signature. With such asymmetric work, it's easy for an 63 attacker or a modestly sized bot-net to overwhelm a server's 64 resources, creating a DoS or distributed DoS (DDoS) attack. 66 The extension described in this document mitigates this attack, by 67 forcing the attacker to perform some work (a partial break of a hash 68 function) before the server agrees to process the ClientKeyExchange. 69 This has a marked effect on the latency, so Section 4 recommends 70 against using this feature when the server is not under extreme load. 72 1.1. Conventions Used in This Document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Protocol Overview 80 A supporting client will send a new empty extension in the 81 ClientHello message. This new extension is called client_puzzle. 83 A supporting server's reply depends on whether the feature is 84 activated or not. It is expected that conforming servers will have 85 an option to set this feature to be unconditionally deactivated and 86 unconditionally activated, but at least the latter will be for 87 testing purposes only. The usual configuration will be to activate 88 the feature dynamically in response to a heavy load which may be a 89 result of an attempt at a DoS attack. 91 When deactivated, the server MAY either respond with an empty 92 client_puzzle extension in its ServerHello, or it MAY omit the 93 extension entirely. Either way, no further action is required from 94 either client or server. TBD: Should we mandate one or the other? 95 When activated, the server SHOULD generate a 32-byte value called a 96 Mystery, and send a non-empty client_puzzle extension as described in 97 Section 2.1. This extension is sent in the ServerHello. Exceptions 98 to the SHOULD-level requirement are in Section 5. 100 A conforming client that has received a non-empty client_puzzle 101 extension MUST respond with one of the following: 102 o Terminate the connection with a decode_error alert if the 103 client_puzzle extension sent by the server was malformed. 104 o Terminate the connection with a puzzle_error alert if either the 105 puzzle is too hard, or all attempts to solve the puzzle failed. 106 This new alert is described in Section 2.2. 107 o A PuzzleSolution handshake message with the solution to the 108 puzzle. This new handshake message is defined in Section 2.3. 109 The client MUST send this new handshake message before the 110 optional Certificate message and the (non-optional) 111 ClientKeyExchange message. 113 When the feature is activated and a puzzle has been sent in the 114 extension, the server MUST NOT process the Certificate or the 115 ClientKeyExchange messages if the PuzzleSolution is missing. In that 116 case, it MUST terminate the connection with a puzzle_error alert. A 117 puzzle_error alert is also used if the solution in the PuzzleSolution 118 message is incorrect. 120 If the puzzle solution is correct, the server continues the handshake 121 normally. 123 The diagram below outlines the protocol structure. 125 Client Server 127 ClientHello(*) --------> 128 ServerHello(*) 129 Certificate* 130 ServerKeyExchange* 131 CertificateRequest* 132 <-------- ServerHelloDone 133 PuzzleSolution 134 Certificate* 135 ClientKeyExchange 136 CertificateVerify* 137 [ChangeCipherSpec] 138 Finished --------> 139 [ChangeCipherSpec] 140 <-------- Finished 141 Application Data <-------> Application Data 143 (*) The ClientHello and ServerHello include the client_puzzle 144 extension to indicate support 146 2.1. The client_puzzle Extension 148 The client_puzzle extension is a ClientHello and ServerHello 149 extension as defined in section 2.3 of [TLS-EXT]. The extension_type 150 field is TBA by IANA. 152 The format of the non-empty extension is to be added, but it has to 153 include the following fields: 154 o A 32-byte field that contains the SHA2-256 hash of the (not 155 transmitted) Mystery. 156 o A 1-byte field that contains the difficulty level of the puzzle. 157 o A 32-byte "masked puzzle" value, which is the same as the Mystery, 158 but with the last n bits set to zero, where n is the number in the 159 difficulty field. 161 2.2. The puzzle_error Alert 163 This alert code is to be assigned by IANA. This alert is always 164 fatal. 166 2.3. The PuzzleSolution Handshake Message 168 The format of the PuzzleSolution record is to be added, but it will 169 contain the 32-byte Mystery. The content type is TBA by IANA. 171 The client finds this value by trying different values for the masked 172 bits in the "masked puzzle" field in the client_puzzle extension. 174 3. Processing 176 3.1. Client Processing 178 The client MUST always send an empty client_puzzle extension in the 179 ClientHello. 181 If no client_puzzle extension is present in the ServerHello, no 182 further action is needed. 184 If an empty client_puzzle extension is present in the ServerHello, no 185 further action is needed. 187 If a non-empty client_puzzle extension is present in the ServerHello, 188 the verify that it is properly formatted and that the difficulty 189 level is acceptable. The difficulty level is acceptable if all 2^n 190 possibilities can be tested by the client in a reasonable amount of 191 time. If either check fails, the client MUST terminate the 192 connection with a puzzle_error alert. 194 The client then proceeds to attempt to solve the puzzle. If the 195 puzzle is unsolvable, the client MUST terminate the connection with a 196 fatal puzzle_error alert. 198 Having found a correct Mystery value, the client sends that value in 199 a PuzzleSolution message, and proceeds with the rest of the TLS 200 handshake. 202 3.2. Server Processing 204 Puzzle protection is enabled or disabled depending on load. See 205 Section 4 for considerations. 207 When disabled, it is acceptable for the client to not send a 208 client_puzzle extension. In this case, the server MUST NOT send a 209 client_puzzle extension. 211 When disabled, if the client does send an empty client_puzzle 212 extension, the server MAY reply with an empty client_puzzle 213 extension. If the feature is administratively disabled, then the 214 server SHOULD NOT send an empty client_puzzle extension, whereas if 215 it's only disabled because the server is not under load, it SHOULD 216 send the extension. 218 When puzzles are enabled, but the client did not send a client_puzzle 219 extension, the server MUST terminate the connection with a 220 puzzle_error alert. 222 When puzzles are enabled and the client has sent an empty 223 client_puzzle extension, the server generates a random 32-byte string 224 called the Mystery. To construct the extension, the server hashes 225 the Mystery, sets a difficulty level (n), and adds the Mystery to the 226 extension data field, clearing the last n bits. The server also 227 stores the Mystery value. 229 When the client returns a PuzzleSolution handshake message, the 230 server compares the Mystery value to the value in the PuzzleSolution. 231 If they match, or if their SHA2-256 hashes match, processing 232 continues as usual. If not, the server MUST terminate the session 233 with a puzzle_error alert. 235 4. Operational Considerations 237 [This section needs a lot of expanding] 239 Not all Clients support this extension, so this protection should 240 only be enabled when the server detects an unusual load that could 241 indicate an attack. Detecting this is beyond the scope of this 242 document. 244 The difficulty level should be set by balancing the requirement to 245 minimize the latency for legitimate clients and making things 246 difficult for attackers. A good rule of thumb is for taking about 1 247 second to solve the puzzle. A typical client or bot-net member in 248 2014 can perform slightly less than a million SHA2-256 hashes per 249 second per core, so setting the difficulty level to n=20 is a good 250 compromise. It should be noted that mobile initiators, especially 251 phones are considerably weaker than that. Implementations should 252 allow administrators to set the difficulty level, and/or be able to 253 set the difficulty level dynamically in response to load. 255 Note that when this feature is enabled, it causes a latency of about 256 one second. Such a delay may be unnoticeable for SMTP servers, but 257 would be very irritating to browser users. These considerations 258 should be taken into account when determining activation thresholds 259 and difficulty levels. 261 Clients should set a maximum difficulty level beyond which they won't 262 try to solve the puzzle and log or display a failure message to the 263 administrator or user. 265 This mechanism is appropriate for TLS. For DTLS, initiating multiple 266 handshakes so as to load the server with memory allocations may be a 267 more attractive attack vector, one that this feature does not protect 268 against. See Appendix A for an alternate design that could be 269 appropriate for DTLS. 271 5. Security Considerations 273 To be added 275 6. IANA Considerations 277 IANA is requested to allocate: 278 o An alert type in the "TLS Alert" registry, with puzzle_error in 279 the Description field, "Y" in the DTLS-OK field, and this document 280 as reference. 281 o An extension type in the "ExtensionType Values" registry. The 282 extension name should be "client_puzzle" and the reference should 283 be this document. 284 o A handshake message type in the "TLS HandshakeType" registry with 285 description "puzzle_solution", "Y" for DTLS-OK, and this document 286 as reference. 288 7. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 294 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 296 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 297 and T. Wright, "Transport Layer Security (TLS) 298 Extensions", RFC 4366, April 2006. 300 Appendix A. An Alternate Design 302 This appendix broadly describes an alternate design. I rejected this 303 in favor of the design in the main part of the document, because that 304 one seemed more appropriate for a TCP-based protocol such as TLS. 306 With this design, the client does not need to indicate support. When 307 the server is under load, it responds to a ClientHello with an alert 308 that carries the puzzle, and terminates the TLS connection. The 309 client then solves the puzzle, and starts a new connection, including 310 the puzzle solution in a ClientHello extension. 312 Advantages of this alternate design: 313 o No state is needed on the server while the client is solving the 314 puzzle. Specifically, no sockets are occupied. 315 o No new handshake messages are required. 316 o Appropriate for DTLS, because the statelessness while the client 317 is solving the puzzle mitigates the state allocation attack. 319 Disadvantages of this alternate design: 320 o Requires an extra TCP handshake, increasing latency in a protocol 321 extension that already has a latency issue. 322 o Has a challenge with recognizing puzzles and preventing re-use of 323 a solution. Mysteries need to be generated in such a way that the 324 server will recognize them as Mysteries that it has generated, and 325 also won't allow re-use of a solved Mystery by multiple clients. 327 The challenge above is not insurmountable. It is possible to 328 generate the Mystery in a stateless way by making it depend on client 329 IP address and on a timestamp. Alternatively, the server can 330 allocate state and store the issued Mysteries, deleting them when 331 they are received to prevent re-use, and expiring them after some 332 appropriate time span (at least round-trip time plus the time it 333 takes the slowest client to solve the puzzle). 335 Author's Address 337 Yoav Nir 338 Check Point Software Technologies Ltd. 339 5 Hasolelim st. 340 Tel Aviv 6789735 341 Israel 343 Email: ynir.ietf@gmail.com