TLS Working Group Y. Nir Internet-Draft Check Point Intended status: Experimental April 29, 2014 Expires: October 31, 2014 Using Client Puzzles to Protect TLS Servers From Denial of Service Attacks draft-nir-tls-puzzles-00 Abstract This document proposes a mechanism for mitigating denial of service (DoS) and distributed denial of service (DDoS) attacks on TLS servers. Attackers are limited in their ability to cause resource waste on the server by requiring proof of work by the client before these CPU resources are expended. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 31, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Nir Expires October 31, 2014 [Page 1] Internet-Draft TLS Client Puzzles April 2014 described in the Simplified BSD License. 1. Introduction TLS ([TLS]) is vulnerable to a simple denial of service (DoS) attack. Arbitrary hosts on the Internet can begin a TLS handshake with a server. The attacking clients need only generate a valid TLS ClientHello and a valid-looking ClientKeyExchange, both of which require very little computing resources. To respond, the server has to perform some CPU-intensive operations. Depending on the chosen ciphersuite, the server will need to perform an RSA decryption or a Diffie-Hellman exchange plus a RSA, DSA, or ECDSA signature. With such asymmetric work, it's easy for an attacker or a modestly sized bot-net to overwhelm a server's resources, creating a DoS or distributed DoS (DDoS) attack. The extension described in this document mitigates this attack, by forcing the attacker to perform some work (a partial break of a hash function) before the server agrees to process the ClientKeyExchange. This has a marked effect on the latency, so Section 4 recommends against using this feature when the server is not under extreme load. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Protocol Overview A supporting client will send a new empty extension in the ClientHello message. This new extension is called client_puzzle. A supporting server's reply depends on whether the feature is activated or not. It is expected that conforming servers will have an option to set this feature to be unconditionally deactivated and unconditionally activated, but at least the latter will be for testing purposes only. The usual configuration will be to activate the feature dynamically in response to a heavy load which may be a result of an attempt at a DoS attack. When deactivated, the server MAY either respond with an empty client_puzzle extension in its ServerHello, or it MAY omit the extension entirely. Either way, no further action is required from either client or server. TBD: Should we mandate one or the other? Nir Expires October 31, 2014 [Page 2] Internet-Draft TLS Client Puzzles April 2014 When activated, the server SHOULD generate a 32-byte value called a Mystery, and send a non-empty client_puzzle extension as described in Section 2.1. This extension is sent in the ServerHello. Exceptions to the SHOULD-level requirement are in Section 5. A conforming client that has received a non-empty client_puzzle extension MUST respond with one of the following: o Terminate the connection with a decode_error alert if the client_puzzle extension sent by the server was malformed. o Terminate the connection with a puzzle_error alert if either the puzzle is too hard, or all attempts to solve the puzzle failed. This new alert is described in Section 2.2. o A PuzzleSolution handshake message with the solution to the puzzle. This new handshake message is defined in Section 2.3. The client MUST send this new handshake message before the optional Certificate message and the (non-optional) ClientKeyExchange message. When the feature is activated and a puzzle has been sent in the extension, the server MUST NOT process the Certificate or the ClientKeyExchange messages if the PuzzleSolution is missing. In that case, it MUST terminate the connection with a puzzle_error alert. A puzzle_error alert is also used if the solution in the PuzzleSolution message is incorrect. If the puzzle solution is correct, the server continues the handshake normally. The diagram below outlines the protocol structure. Nir Expires October 31, 2014 [Page 3] Internet-Draft TLS Client Puzzles April 2014 Client Server ClientHello(*) --------> ServerHello(*) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone PuzzleSolution Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data (*) The ClientHello and ServerHello include the client_puzzle extension to indicate support 2.1. The client_puzzle Extension The client_puzzle extension is a ClientHello and ServerHello extension as defined in section 2.3 of [TLS-EXT]. The extension_type field is TBA by IANA. The format of the non-empty extension is to be added, but it has to include the following fields: o A 32-byte field that contains the SHA2-256 hash of the (not transmitted) Mystery. o A 1-byte field that contains the difficulty level of the puzzle. o A 32-byte "masked puzzle" value, which is the same as the Mystery, but with the last n bits set to zero, where n is the number in the difficulty field. 2.2. The puzzle_error Alert This alert code is to be assigned by IANA. This alert is always fatal. 2.3. The PuzzleSolution Handshake Message The format of the PuzzleSolution record is to be added, but it will contain the 32-byte Mystery. The content type is TBA by IANA. The client finds this value by trying different values for the masked Nir Expires October 31, 2014 [Page 4] Internet-Draft TLS Client Puzzles April 2014 bits in the "masked puzzle" field in the client_puzzle extension. 3. Processing 3.1. Client Processing The client MUST always send an empty client_puzzle extension in the ClientHello. If no client_puzzle extension is present in the ServerHello, no further action is needed. If an empty client_puzzle extension is present in the ServerHello, no further action is needed. If a non-empty client_puzzle extension is present in the ServerHello, the verify that it is properly formatted and that the difficulty level is acceptable. The difficulty level is acceptable if all 2^n possibilities can be tested by the client in a reasonable amount of time. If either check fails, the client MUST terminate the connection with a puzzle_error alert. The client then proceeds to attempt to solve the puzzle. If the puzzle is unsolvable, the client MUST terminate the connection with a fatal puzzle_error alert. Having found a correct Mystery value, the client sends that value in a PuzzleSolution message, and proceeds with the rest of the TLS handshake. 3.2. Server Processing Puzzle protection is enabled or disabled depending on load. See Section 4 for considerations. When disabled, it is acceptable for the client to not send a client_puzzle extension. In this case, the server MUST NOT send a client_puzzle extension. When disabled, if the client does send an empty client_puzzle extension, the server MAY reply with an empty client_puzzle extension. If the feature is administratively disabled, then the server SHOULD NOT send an empty client_puzzle extension, whereas if it's only disabled because the server is not under load, it SHOULD send the extension. When puzzles are enabled, but the client did not send a client_puzzle Nir Expires October 31, 2014 [Page 5] Internet-Draft TLS Client Puzzles April 2014 extension, the server MUST terminate the connection with a puzzle_error alert. When puzzles are enabled and the client has sent an empty client_puzzle extension, the server generates a random 32-byte string called the Mystery. To construct the extension, the server hashes the Mystery, sets a difficulty level (n), and adds the Mystery to the extension data field, clearing the last n bits. The server also stores the Mystery value. When the client returns a PuzzleSolution handshake message, the server compares the Mystery value to the value in the PuzzleSolution. If they match, or if their SHA2-256 hashes match, processing continues as usual. If not, the server MUST terminate the session with a puzzle_error alert. 4. Operational Considerations [This section needs a lot of expanding] Not all Clients support this extension, so this protection should only be enabled when the server detects an unusual load that could indicate an attack. Detecting this is beyond the scope of this document. The difficulty level should be set by balancing the requirement to minimize the latency for legitimate clients and making things difficult for attackers. A good rule of thumb is for taking about 1 second to solve the puzzle. A typical client or bot-net member in 2014 can perform slightly less than a million SHA2-256 hashes per second per core, so setting the difficulty level to n=20 is a good compromise. It should be noted that mobile initiators, especially phones are considerably weaker than that. Implementations should allow administrators to set the difficulty level, and/or be able to set the difficulty level dynamically in response to load. Note that when this feature is enabled, it causes a latency of about one second. Such a delay may be unnoticeable for SMTP servers, but would be very irritating to browser users. These considerations should be taken into account when determining activation thresholds and difficulty levels. Clients should set a maximum difficulty level beyond which they won't try to solve the puzzle and log or display a failure message to the administrator or user. This mechanism is appropriate for TLS. For DTLS, initiating multiple Nir Expires October 31, 2014 [Page 6] Internet-Draft TLS Client Puzzles April 2014 handshakes so as to load the server with memory allocations may be a more attractive attack vector, one that this feature does not protect against. See Appendix A for an alternate design that could be appropriate for DTLS. 5. Security Considerations To be added 6. IANA Considerations IANA is requested to allocate: o An alert type in the "TLS Alert" registry, with puzzle_error in the Description field, "Y" in the DTLS-OK field, and this document as reference. o An extension type in the "ExtensionType Values" registry. The extension name should be "client_puzzle" and the reference should be this document. o A handshake message type in the "TLS HandshakeType" registry with description "puzzle_solution", "Y" for DTLS-OK, and this document as reference. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. Appendix A. An Alternate Design This appendix broadly describes an alternate design. I rejected this in favor of the design in the main part of the document, because that one seemed more appropriate for a TCP-based protocol such as TLS. With this design, the client does not need to indicate support. When the server is under load, it responds to a ClientHello with an alert that carries the puzzle, and terminates the TLS connection. The client then solves the puzzle, and starts a new connection, including Nir Expires October 31, 2014 [Page 7] Internet-Draft TLS Client Puzzles April 2014 the puzzle solution in a ClientHello extension. Advantages of this alternate design: o No state is needed on the server while the client is solving the puzzle. Specifically, no sockets are occupied. o No new handshake messages are required. o Appropriate for DTLS, because the statelessness while the client is solving the puzzle mitigates the state allocation attack. Disadvantages of this alternate design: o Requires an extra TCP handshake, increasing latency in a protocol extension that already has a latency issue. o Has a challenge with recognizing puzzles and preventing re-use of a solution. Mysteries need to be generated in such a way that the server will recognize them as Mysteries that it has generated, and also won't allow re-use of a solved Mystery by multiple clients. The challenge above is not insurmountable. It is possible to generate the Mystery in a stateless way by making it depend on client IP address and on a timestamp. Alternatively, the server can allocate state and store the issued Mysteries, deleting them when they are received to prevent re-use, and expiring them after some appropriate time span (at least round-trip time plus the time it takes the slowest client to solve the puzzle). Author's Address Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 6789735 Israel Email: ynir.ietf@gmail.com Nir Expires October 31, 2014 [Page 8]