NIST SP 800-52 Rev. 2 日本語訳

NIST Special Publication 800-52

Revision 2

Kerry A. McKay David A. Cooper

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-52r2

NIST Special Publication 800-52

Revision 2

Kerry A. McKay David A. Cooper

Computer Security Division Information Technology Laboratory

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-52r2

August 2019

U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary

National Institute of Standards and Technology

Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-52 Revision 2 Natl. Inst. Stand. Technol. Spec. Publ. 800-52 Rev. 2, 72 pages (August 2019) CODEN: NSPUE2

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-52r2

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

原本PDFの抜粋画像

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: sp80052-comments@nist.gov

All comments are subject to release under the Freedom of Information Act (FOIA).

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

Transport Layer Security (TLS) provides mechanisms to protect data during electronic dissemination across the Internet. This Special Publication provides guidance to the selection and configuration of TLS protocol implementations while making effective use of Federal Information Processing Standards (FIPS) and NIST-recommended cryptographic algorithms. It requires that TLS 1.2 configured with FIPS-based cipher suites be supported by all government TLS servers and clients and requires support for TLS 1.3 by January 1, 2024. This Special Publication also provides guidance on certificates and TLS extensions that impact security.

information security; network security; SSL; TLS; Transport Layer Security

Acknowledgements

The authors, Kerry McKay and David Cooper of the National Institute of Standards and Technology (NIST), would like to thank the many people who assisted with the development of this document. In particular, we would like to acknowledge Tim Polk of NIST and Santosh Chokhani of CygnaCom Solutions, who were co-authors on the first revision of this document. We would also like to acknowledge Matthew J. Fanto and C. Michael Chernick of NIST and Charles Edington III and Rob Rosenthal of Booz Allen Hamilton who wrote the initial published version of this document.

Audience

This document assumes that the reader of these guidelines is familiar with TLS protocols and public-key infrastructure concepts, including, for example, X.509 certificates.

The guidelines in this document are specifically targeted towards U.S. federal departments and agencies. While these guidelines will generally be of use to other readers, information about recommended cryptographic algorithms may not apply to non-federal readers if it is inconsistent with the policies of the readers’ organizations.

Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource, requires managers of public-facing information repositories or dissemination systems that contain sensitive but unclassified data to ensure that sensitive data is protected commensurate with the risk and magnitude of the harm that would result from the loss, misuse, or unauthorized access to or modification of such data. Given the nature of interconnected networks and the use of the Internet to share information, the protection of this sensitive data can become difficult if proper mechanisms are not employed to protect the data. Transport Layer Security (TLS) provides such a mechanism to protect sensitive data during electronic dissemination across the Internet.

TLS is a protocol created to provide authentication, confidentiality, and data integrity protection between two communicating applications. TLS is based on a precursor protocol called the Secure Sockets Layer Version 3.0 (SSL 3.0) and is considered to be an improvement to SSL 3.0. SSL 3.0 is specified in [32]. The Transport Layer Security version 1 (TLS 1.0) is specified in Request for Comments (RFC) 2246 [23]. Each document specifies a similar protocol that provides security services over the Internet. TLS 1.0 has been revised to version 1.1, as documented in RFC 4346 [24], and TLS 1.1 has been further revised to version 1.2, as documented in RFC 5246 [25]. In addition, some extensions have been defined to mitigate some of the known security vulnerabilities in implementations using TLS versions 1.0, 1.1, and 1.2. TLS 1.3, described in RFC 8446 [57], is a significant update to previous versions that includes protections against security concerns that arose in previous versions of TLS.

This Special Publication provides guidance on the selection and configuration of TLS protocol implementations while making effective use of NIST-approved cryptographic schemes and algorithms. In particular, it requires that TLS 1.2 be configured with cipher suites using NIST-approved schemes and algorithms as the minimum appropriate secure transport protocol and requires support for TLS 1.3 by January 1, 2024.1 When interoperability with non-government systems is required, TLS 1.1 and TLS 1.0 may be supported. This Special Publication also identifies TLS extensions for which mandatory support must be provided and also identifies other recommended extensions.

The use of the recommendations provided in this Special Publication are intended to promote:

While these guidelines are primarily designed for federal users and system administrators to adequately protect sensitive but unclassified U.S. Federal Government data against serious threats on the Internet, they may also be used within closed network environments to segregate data. (The client-server model and security services discussed also apply in these situations). This Special Publication supersedes NIST Special Publication 800-52 Revision 1. This Special Publication should be used in conjunction with existing policies and procedures.

Transport Layer Security (TLS) protocols are used to secure communications in a wide variety of online transactions, such as financial transactions (e.g., banking, trading stocks, e-commerce), healthcare transactions (e.g., viewing medical records or scheduling medical appointments), and social transactions (e.g., email or social networking). Any network service that handles sensitive or valuable data, whether it is personally identifiable information (PII), financial data, or login information, needs to adequately protect that data. TLS provides a protected channel for sending data between a server and a client. The client is often, but not always, a web browser. Memorandum M-15-132 requires that all publicly accessible federal websites and web services only provide service through a secure connection.³ The initiative to secure connections will enhance privacy and prevent modification of the data from government sites in transit.

TLS is a layered protocol that runs on top of a reliable transport protocol—typically the Transmission Control Protocol (TCP). Application protocols, such as the Hypertext Transfer Protocol (HTTP) and the Internet Message Access Protocol (IMAP), can run above TLS. TLS is application-independent and used to provide security to any two communicating applications that transmit data over a network via an application protocol.

The Secure Sockets Layer (SSL) protocol was designed by the Netscape Corporation to meet the security needs of client and server applications. Version 1 of SSL was never released. SSL 2.0 was released in 1995 but had well-known security vulnerabilities, which were addressed by the 1996 release of SSL 3.0. During this timeframe, the Microsoft Corporation released a protocol known as Private Communications Technology (PCT) and later released a higher-performance protocol known as the Secure Transport Layer Protocol (STLP). PCT and STLP never commanded the market share that SSL 2.0 and SSL 3.0 commanded. The Internet Engineering Task Force (IETF), a technical working group responsible for developing Internet standards to ensure communications compatibility across different implementations, attempted to resolve security engineering and protocol incompatibility issues between the protocols as best it could. The IETF standards track Transport Layer Security protocol Version 1.0 (TLS 1.0) emerged and was codified by the IETF as Request for Comments (RFC) 2246 [23]. While TLS 1.0 is based on SSL 3.0, and the differences between them are not dramatic, they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate.

TLS 1.1, specified in RFC 4346 [24], was developed to address weaknesses discovered in TLS 1.0, primarily in the areas of initialization vector selection and padding error processing. Initialization vectors were made explicit⁴ to prevent a certain class of attacks on the Cipher

Block Chaining (CBC) mode of operation used by TLS. The handling of padding errors was altered to treat a padding error as a bad message authentication code rather than a decryption failure. In addition, the TLS 1.1 RFC acknowledges attacks on CBC mode that rely on the time to compute the message authentication code (MAC). The TLS 1.1 specification states that to defend against such attacks, an implementation must process records in the same manner regardless of whether padding errors exist. Further implementation considerations for CBC modes (which were not included in RFC 4346 [24]) are discussed in Section 3.3.2.

TLS 1.2, specified in RFC 5246 [25], made several cryptographic enhancements, particularly in the area of hash functions, with the ability to use or specify the SHA-2 family of algorithms for hash, MAC, and Pseudorandom Function (PRF) computations. TLS 1.2 also adds authenticated encryption with associated data (AEAD) cipher suites.

TLS 1.3, specified in RFC 8446 [57], represents a significant change to TLS that aims to address threats that have arisen over the years. Among the changes are a new handshake protocol, a new key derivation process that uses the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) [37], and the removal of cipher suites that use RSA key transport or static Diffie-Hellman (DH) key exchanges, the CBC mode of operation, or SHA-1. Many extensions defined for use with TLS 1.2 and previous versions cannot be used with TLS 1.3.

Security is not a single property that is (or is not) possessed by a protocol. Rather, security includes a complex set of related properties that together provide the required information assurance characteristics and information protection services. Security requirements are usually derived from a risk assessment of the threats or attacks that an adversary is likely to mount against a system. The adversary is likely to take advantage of implementation vulnerabilities found in many system components, including computer operating systems, application software systems, and the computer networks that interconnect them. Thus, in order to secure a system against a myriad of threats, security must be judiciously placed in the various systems and network layers.

These guidelines focus only on network security, and they focus directly on the small portion of the network communications stack that is referred to as the transport layer. Several other NIST publications address security requirements in the other parts of the system and network layers. Adherence to these guidelines only protects the data in transit. Other applicable NIST standards and guidelines should be used to ensure protection of systems and stored data.

These guidelines focus on the common use cases where clients and servers must interoperate with a wide variety of implementations, and authentication is performed using public-key certificates. To promote interoperability, implementations often support a wide array of cryptographic options. However, there are much more constrained TLS implementations where security is needed but broad interoperability is not required, and the cost of implementing unused features may be prohibitive. For example, minimal servers are often implemented in embedded controllers and network infrastructure devices, such as routers, and then used with browsers to remotely configure and manage the devices. There are also cases where both the client and server for an application’s TLS connection are under the control of the same entity, and therefore allowing a variety of options for interoperability is not necessary. The use of an appropriate subset of the capabilities specified in these guidelines may be acceptable in such cases.

The scope is further limited to TLS when used in conjunction with TCP/IP. For example, Datagram TLS (DTLS), which operates over datagram protocols, is outside the scope of these guidelines. NIST may issue separate guidelines for DTLS at a later date.

TLS may be used to secure the communications of a wide variety of applications in a diverse set of operating environments. As such, there is not a single configuration that will work well for all scenarios. These guidelines attempt to provide general-use recommendations. However, the needs of an agency or application may differ from general needs. Deviations from these guidelines are acceptable, provided that agencies and system administrators assess and accept the risks associated with alternative configurations in terms of both security and interoperability.

Throughout this document, key words are used to identify requirements. The key words “shall,” “shall not,” “should,” and “should not” are used. These words are a subset of the IETF Request for Comments (RFC) 2119 key words, and have been chosen based on convention in other normative documents [15]. In addition to the key words, the words “need,” “can,” and “may” are used in this document but are not intended to be normative. The key words “NIST-approved” and “NIST-recommended” are used to indicate that a scheme or algorithm is described in a Federal Information Processing Standard (FIPS) or is recommended by NIST in a Special Publication (SP).

The recommendations in this document are grouped by server recommendations and client recommendations. Section 3 provides detailed guidance for the selection and configuration of TLS servers. Section 4 provides detailed guidance for the selection, configuration, and use of TLS clients.

TLS exchanges records via the TLS record protocol. A TLS record contains several fields, including version information, application protocol data, and the higher-level protocol used to process the application data. TLS protects the application data by using a set of cryptographic algorithms to ensure the confidentiality, integrity, and authenticity of exchanged application data. TLS defines several protocols for connection management that sit on top of the record protocol, where each protocol has its own record type. These protocols, discussed in Section 2.1, are used to establish and change security parameters and to communicate error and warning conditions to the server and client. Sections 2.2 through 2.6 describe the security services provided by the TLS protocol and how those security services are provisioned. Section 2.7 discusses key management.

There are three subprotocols in the TLS protocol that are used to control the session connection: the handshake, change cipher spec, and alert protocols. The TLS handshake protocol is used to negotiate the session parameters. The alert protocol is used to notify the other party of an error condition. The change cipher spec protocol is used in TLS 1.0, 1.1, and 1.2 to change the cryptographic parameters of a session. In addition, the client and the server exchange application data that is protected by the security services provisioned by the negotiated cipher suite. These security services are negotiated and established with the handshake.

The handshake protocol consists of a series of message exchanges between the client and the server. The handshake protocol initializes both the client and server to use cryptographic capabilities by negotiating a cipher suite of algorithms and functions, including key establishment, digital signature, confidentiality, and integrity algorithms. Clients and servers can be configured so that one or more of the following security services are negotiated during the handshake: confidentiality, message integrity, authentication, and replay protection. A confidentiality service provides assurance that data is kept secret, preventing eavesdropping. A message integrity service provides confirmation that unauthorized data modification is detected, thus preventing undetected deletion, addition, or modification of data. An authentication service provides assurance of the sender or receiver’s identity, thereby detecting forgery. Replay protection ensures that an unauthorized user does not capture and successfully replay previous data. In order to comply with these guidelines, both the client and the server must be configured for data confidentiality and integrity services.

The handshake protocol is used to optionally exchange X.509 public-key certificates⁵ to authenticate the server to the client and may be used to authenticate the client to the server as well.

The handshake protocol is responsible for establishing the session parameters. The client and server negotiate algorithms for authentication, confidentiality, and integrity, as well as derive symmetric keys and establish other session parameters, such as extensions. The negotiated set of cryptographic algorithms is called the cipher suite.

Alerts are used to convey information about the session, such as errors or warnings. For example, an alert can be used to signal a decryption error (decrypt_error) or that access has been denied (access_denied). Some alerts are used for warnings, and others are considered fatal and lead to immediate termination of the session. A close_notify alert message is used to signal the normal termination of a session. Like all other messages after the handshake protocol is completed, alert messages are encrypted (and optionally compressed in TLS versions prior to TLS 1.3).

Details of the handshake, change cipher spec (in TLS versions prior to 1.3), and alert protocols are outside the scope of these guidelines; they are described in RFC 5246 [25] and RFC 8446 [57].

The client and server establish keying material during the TLS handshake protocol. The derivation of the premaster secret depends on the key exchange method that is agreed upon and the version of TLS used. For example, when Diffie-Hellman is used as the key-exchange algorithm in TLS 1.2 and earlier versions, the client and server send each other their parameters, which are then used to compute the premaster secret. The premaster secret, along with random values exchanged by the client and server in the hello messages, is used in a pseudorandom function (PRF) to compute the master secret. In TLS 1.3, the master secret is derived by iteratively invoking an extract-then-expand function with previously derived secrets. The master secret is used to derive session keys, which are used by the negotiated security services to protect the data exchanged between the client and the server, thus providing a secure channel for the client and the server to communicate.

The establishment of these secrets is secure against eavesdroppers. When the TLS protocol is used in accordance with these guidelines, the application data, as well as the secrets, are not vulnerable to attackers who place themselves in the middle of the connection. The attacker cannot modify the handshake messages without being detected by the client and the server because the Finished message, which is exchanged after security parameter establishment, provides integrity protection for the entire exchange. In other words, an attacker cannot modify or downgrade the security of the connection by placing itself in the middle of the negotiation.

Confidentiality is provided for a communication session by the negotiated encryption algorithm for the cipher suite and the encryption keys derived from the master secret and random values, one for encryption by the client (the client write key) and another for encryption by the server (the server write key). The sender of a message (client or server) encrypts the message using the appropriate derived encryption key; the receiver uses the same (independently derived) key to decrypt the message. Both the client and server know these keys and decrypt the messages using the same key that was used for encryption.

The keyed MAC algorithm, specified by the negotiated cipher suite, provides message integrity. As with confidentiality, there is a different key for each direction of communication. The sender of a message (client or server) calculates the MAC for the message using the appropriate MAC key (the client write MAC secret or the server write MAC secret). When the receiver processes the message, it calculates its own version of the MAC using the MAC algorithm and sender’s write MAC key. The receiver verifies that the MAC that it calculates matches the MAC received in the message from the sender.

Two types of constructions are used for MAC algorithms in TLS. TLS versions 1.0, 1.1, and 1.2 support the use of the Keyed-Hash Message Authentication Code (HMAC) using the hash algorithm specified by the negotiated cipher suite. With HMAC, MACs for server-to-client messages are keyed by the server write MAC key, while MACs for client-to-server messages are keyed by the client write MAC key. These MAC keys are derived from the shared master secret.

TLS 1.2 added AEAD cipher modes of operation, such as Counter with CBC-MAC (CCM) [41] and Galois Counter Mode (GCM) [56, 61], as an alternative way of providing integrity and confidentiality. In AEAD modes, the sender uses its write key for both encryption and integrity protection. The client and server write MAC keys are not used. The recipient decrypts the message and verifies the integrity information using the sender's write key. In TLS 1.3, only AEAD symmetric algorithms are used for confidentiality and integrity.

Server authentication is performed by the client using the server’s public-key certificate, which the server presents during the handshake. The exact nature of the cryptographic operation for server authentication is dependent on the negotiated security parameters and extensions. In many cases, authentication is performed explicitly by verifying digital signatures using public keys that are present in certificates or implicitly by the use of the server public key by the client during the establishment of the master secret. A successful Finished message implies that both parties calculated the same master secret, and thus, the server must have known the private key corresponding to the public key in the server’s certificate.

Client authentication is optional and only occurs at the server’s request. Client authentication is based on the client’s public-key certificate. The exact nature of the cryptographic operation for client authentication depends on the negotiated cipher suite’s key-exchange algorithm and the negotiated extensions. For example, when the client’s public-key certificate contains an RSA public key, the client signs a portion of the handshake message using the private key corresponding to that public key, and the server verifies the signature using the client's public key to authenticate the client.

TLS provides inherent protection against replay attacks, except when 0-RTT data (optionally sent in the first flight of handshake messages) is sent in TLS 1.3.6 The integrity-protected envelope of the message contains a monotonically increasing sequence number. Once the message integrity is verified, the sequence number of the current message is compared with the sequence number of the previous message. The sequence number of the current message must be greater than the sequence number of the previous message in order to further process the message.

The security of the server’s private key is critical to the security of TLS. If the server’s private key is weak or can be obtained by a third party, the third party can masquerade as the server to all clients. Similarly, if a third party can obtain a public-key certificate for a public key corresponding to its own private key in the name of a legitimate server from a certification authority (CA) trusted by the clients, the third party can masquerade as the server to the clients. Requirements and recommendations to mitigate these concerns are addressed later in these guidelines.

Similar threats exist for clients. If a client’s private key is weak or can be obtained by a third party, the third party can masquerade as the client to a server. Similarly, if a third party can obtain a public-key certificate for a public key corresponding to his own private key in the name of a client from a CA trusted by the server, the third party can masquerade as that client to the server. Requirements and recommendations to mitigate these concerns are addressed later in these guidelines.

Since the random numbers generated by the client and server contribute to the randomness of the session keys, the client and server must be capable of generating random numbers with at least 112 bits of security⁷ each. The various TLS session keys derived from these random values and other data are valid for the duration of the session. Because the session keys are only used to protect messages exchanged during an active TLS session and are not used to protect any data at rest, there is no requirement for recovering TLS session keys. However, all versions of TLS provide mechanisms to store a key related to a session, which allow sessions to be resumed in the future. Keys for a resumed session are derived during an abbreviated handshake that uses the stored key as a form of authentication.

This section provides a minimum set of requirements that a server must implement in order to meet these guidelines. Requirements are organized in the following sections: TLS protocol version support, server keys and certificates, cryptographic support, TLS extension support, client authentication, session resumption, compression methods, and operational considerations.

Specific requirements are stated as either implementation requirements or configuration requirements. Implementation requirements indicate that federal agencies shall not procure TLS server implementations unless they include the required functionality or can be augmented with additional commercial products to meet the requirements. Configuration requirements indicate that TLS server administrators are required to verify that particular features are enabled or disabled, or in some cases, configured appropriately, if present.

Servers that support government-only applications⁸ shall be configured to use TLS 1.2 and should be configured to use TLS 1.3 as well. These servers should not be configured to use TLS 1.1 and shall not use TLS 1.0, SSL 3.0, or SSL 2.0. TLS versions 1.2 and 1.3 are represented by major and minor number tuples (3, 3) and (3, 4), respectively, and may appear in that format during configuration.⁹

Servers that support citizen or business-facing applications (i.e., the client may not be part of a government IT system)¹⁰ shall be configured to negotiate TLS 1.2 and should be configured to negotiate TLS 1.3. The use of TLS versions 1.1 and 1.0 is generally discouraged, but these versions may be configured when necessary to enable interaction with citizens and businesses. See Appendix F for a discussion on determining whether to support TLS 1.0 and TLS 1.1. These servers shall not allow the use of SSL 2.0 or SSL 3.0.

Agencies shall support TLS 1.3 by January 1, 2024. After this date, servers shall support TLS 1.3 for both government-only and citizen or business-facing applications. In general, servers that support TLS 1.3 should be configured to use TLS 1.2 as well. However, TLS 1.2 may be disabled on servers that support TLS 1.3 if it has been determined that TLS 1.2 is not needed for interoperability.

Some server implementations are known to implement version negotiation incorrectly. For example, there are TLS 1.0 servers that terminate the connection when the client offers a version newer than TLS 1.0. Servers that incorrectly implement TLS version negotiation shall not be used.

The TLS server shall be configured with one or more public-key certificates and the associated private keys. TLS server implementations should support the use of multiple server certificates with their associated private keys to support algorithm and key size agility.

Several options for TLS server certificates meet the requirement for NIST-approved cryptography: an RSA signature certificate, an Elliptic Curve Digital Signature Algorithm (ECDSA) signature certificate, a Digital Signature Algorithm (DSA)¹¹ signature certificate, a Diffie-Hellman (DH) certificate, and an Elliptic Curve Diffie-Hellman (ECDH) certificate. At a minimum, TLS servers conforming to this specification shall be configured with an RSA signature certificate or an ECDSA signature certificate. The other certificate types and their associated cipher suites are not commonly used, especially in externally-accessible servers, but are included in these guidelines for completeness and to cover edge cases. If the server is configured with an ECDSA signature certificate, either curve P-256 or curve P-384 should be used for the public key in the certificate.¹²

TLS servers shall be configured with certificates issued by a CA that publishes revocation information in Online Certificate Status Protocol (OCSP) [63] responses. The CA may additionally publish revocation information in a certificate revocation list (CRL) [19]. The source(s) for the revocation information shall be included in the CA-issued certificate in the appropriate extension to promote interoperability.

A TLS server that has been issued certificates by multiple CAs can select the appropriate certificate based on the client-specified “Trusted CA Keys” TLS extension (see Section 3.4.2.6). A TLS server that has been issued certificates for multiple server names can select the appropriate certificate based on the client-specified “Server Name” TLS extension (see Section 3.4.1.2). A TLS server certificate may also contain multiple names in the Subject Alternative Name extension in order to allow the use of multiple server names of the same name form, such as a Domain Name System (DNS) name, or multiple server names of multiple name forms (e.g., DNS names, IP address, etc.).

Application processes for obtaining certificates differ and require different levels of proof when associating certificates to domains. An applicant can obtain a domain-validated (DV) certificate by proving control over a DNS domain. An Organization Validation (OV) certificate requires further vetting. An Extended Validation (EV) certificate has the most thorough identity vetting process. This recommendation does not provide guidance on which verification level to use.

Section 3.2.1 specifies a detailed profile for server certificates. Basic guidelines for RSA, ECDSA, DSA, DH, and ECDH certificates are provided. Section 3.2.2 specifies requirements for revocation checking. Section 3.5.4 specifies requirements for the “hints list.”

The server certificate profile, described in this section, provides requirements and recommendations for the format of the server certificate. To comply with these guidelines, the TLS server certificate shall be an X.509 version 3 certificate; both the public key contained in the certificate and the signature shall provide at least 112 bits of security. Prior to TLS 1.2, the server Certificate message required that the signing algorithm for the certificate be the same as the algorithm for the certificate key (see Section 7.4.2 of [24]). If the server supports TLS versions prior to TLS 1.2, the certificate should be signed with an algorithm consistent with the public key:¹³,14

The extended key usage extension limits how the keys in a certificate are used. There is a key purpose specifically for server authentication, and the server should be configured to allow its use. The use of the extended key usage extension will facilitate successful server authentication, as some clients may require the presence of an extended key usage extension. The use of the server DNS name in the Subject Alternative Name field ensures that any name constraints on the certification path will be properly enforced.

The server certificate profile is listed in Table 3-1. In the absence of agency-specific certificate profile requirements, this certificate profile should be used for the server certificate.

Table 3-1: TLS Server Certificate Profile

The server shall perform revocation checking of the client certificate when client authentication is used. Revocation information shall be obtained by the server from one or more of the following locations:

When the local store does not have the current or a cogent¹⁶ CRL or OCSP response and the OCSP responder and the CRL distribution point are unavailable or inaccessible at the time of TLS session establishment, the server will either deny the connection or accept a potentially revoked or compromised certificate. The decision to accept or reject a certificate in this situation should be made according to agency policy.

The policies, procedures, and security controls under which a public-key certificate is issued by a CA are documented in a certificate policy. The use of a certificate policy that is designed with the secure operation of Public Key Infrastucture (PKI) in mind and adherence to the stipulated certificate policy mitigates the threat that the issuing CA can be compromised or that the registration system, persons, or process can be compromised to obtain an unauthorized certificate in the name of a legitimate entity and thus compromise the clients. With this in mind, the CA Browser Forum, a private-sector organization, has carried out some efforts in this area by writing requirements for issuing certificates from publicly trusted CAs in order for those CAs and their trust anchor to remain in browser trust stores [16]. Under another effort, the CA Browser Forum has written guidelines for issuing Extended Validation Certificates [17].

Several concepts are under development that further mitigate the risks associated with the compromise of a CA or X.509 certificate registration system, process, or personnel. These include the Certificate Transparency project (see Section 3.4.2.15) and other emerging concepts, which are discussed in Appendix E.

The policy under which a certificate has been issued may optionally be represented in the certificate using the certificatePolicies extension, specified in [19] and updated in [72]. When used, one or more certificate policy object identifiers (OID) are asserted in this extension, with each OID representing a specific certificate policy. Many TLS clients (e.g., browsers), however, do not offer the ability to accept or reject certificates based on the policies under which they were issued. Therefore, it is generally necessary for TLS server certificates to be issued by CAs that only issue certificates in accordance with a certificate policy that specifies adequate security controls.

When an agency is obtaining a certificate for a TLS server for which all the clients are under the agency’s control, the agency may issue the certificate from its own CA if it can configure the clients to trust that CA. In other cases, the agency should obtain a certificate from a publicly-trusted CA (a CA that clients that will be connecting to the server have already been configured to trust).

Cryptographic support in TLS is provided through the use of various cipher suites. A cipher suite specifies a collection of algorithms for key exchange (in TLS 1.2 and earlier only)¹⁷ and for providing confidentiality and integrity services to application data. The cipher suite negotiation occurs during the TLS handshake protocol. The client presents cipher suites that it supports to the server, and the server selects one of them to secure the session data.

In addition to the selection of appropriate cipher suites, system administrators may also have additional considerations specific to the implementation of the cryptographic algorithms, as well as cryptographic module validation requirements. Acceptable cipher suites are listed in Section 3.3.1, grouped by certificate type and protocol version. Cipher suite implementation considerations are discussed in Section 3.3.2, and recommendations regarding cryptographic module validation are described in Section 3.3.3.

Cipher suites specify the cryptographic algorithms that will be used for a session. Cipher suites in TLS 1.0 through TLS 1.2 have the form:

TLS_KeyExchangeAlg_WITH_EncryptionAlg_MessageAuthenticationAlg

For example, the cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA uses ephemeral ECDH key establishment with parameters signed using RSA, confidentiality provided by AES-128 (Advanced Encryption Standard with 128-bit key) in cipher block chaining mode, and message authentication performed using HMAC_SHA.¹⁸ For further information on cipher suite interpretation, see Appendix B.

Cipher suites are defined differently in TLS 1.3. These cipher suites do not specify the key exchange algorithm and have the form:

For example, the cipher suite TLS_AES_128_GCM_SHA256 uses AES-128 in Galois Counter Mode for confidentiality and message authentication and uses SHA-256 for the PRF. TLS 1.3 cipher suites cannot be negotiated for TLS 1.2 connections, and TLS 1.2 cipher suites cannot be negotiated with TLS 1.3.

When negotiating a cipher suite, the client sends a handshake message with a list of cipher suites it will accept. The server chooses from the list and sends a handshake message back indicating which cipher suite it will accept. Although the client may order the list with what it considers to be the strongest cipher suites listed first, the server may ignore the preference order and choose any of the cipher suites proposed by the client. The server may have its own cipher suite preference order, and it may be different from the client’s. Therefore, there is no guarantee that the negotiation will settle on the strongest common suite. If no cipher suites are common to the client and server, the connection is aborted.

The server shall be configured to only use cipher suites that are composed entirely of NIST-approved algorithms (i.e., [6, 7, 9, 26-28, 44-46, 49]). A complete list of acceptable cipher suites for general use is provided in this section, grouped by certificate type and TLS protocol version. The Internet Assigned Numbers Authority (IANA) value for each cipher suite is given after its text description in parentheses.¹⁹

In some situations, such as closed environments, it may be appropriate to use pre-shared keys. Pre-shared keys are symmetric keys that are already in place prior to the initiation of a TLS session and are used in the derivation of the premaster secret. For cipher suites that are acceptable in pre-shared key environments, see Appendix C.

NIST is deprecating the use of RSA key transport as used in TLS. Some applications or environments may require the use of RSA key transport during a transition period. Acceptable cipher suites for use in this situation are located in Appendix D.

The following cipher suite listings are grouped by certificate type and TLS protocol version. The cipher suites in these lists include the cipher suites that contain NIST-approved cryptographic algorithms. Cipher suites that do not appear in this section, Appendix C, or Appendix D shall not be used.

Cipher suites using ephemeral DH and ephemeral ECDH (i.e., those with DHE or ECDHE in the second mnemonic) provide perfect forward secrecy.²⁰ When ephemeral keys are used to establish the master secret, each ephemeral key-pair (i.e., the server ephemeral key-pair and the client ephemeral key-pair) shall have at least 112 bits of security.

The first revision of this guidance required support for a small set of cipher suites to promote interoperability and align with TLS specifications. There are no longer any mandatory cipher suite requirements. Cipher suites that comprise AES and other NIST-approved algorithms are acceptable to use, although they are not necessarily equal in terms of security. Cipher suites that use the Triple Data Encryption Aglorithm (TDEA, also written as 3DES) are no longer allowed due to the limited amounts of data that can be processed under a single key. The server shall be configured to only use cipher suites for which it has a valid certificate containing a signature providing at least 112 bits of security.

By removing requirements that specific cipher suites be supported, system administrators have more freedom to meet the needs of their environments and applications. It also increases agility by allowing administrators to immediately disable cipher suites when attacks are discovered without breaking compliance.

If a subset of the cipher suites that are acceptable for the server certificate(s) are supported, the following list gives general guidance on choosing the strongest options:

This list does not have to be strictly followed, as some environments or applications may have special circumstances. Note that this list may become outdated if an attack emerges on one of the preferred components. If an attack significantly impacts the recommended cipher suites, NIST will address the issue in an announcement on the NIST Computer Security Resource Center website (https://csrc.nist.gov).

TLS version 1.2 includes authenticated encryption modes and support for the SHA-256 and SHA-384 hash algorithms, which are not supported in prior versions of TLS. These cipher suites are described in [61] and [56]. TLS 1.2 servers that are configured with ECDSA certificates may be configured to support the following cipher suites, which are only supported by TLS 1.2:

TLS servers may be configured to support the following cipher suites when ECDSA certificates are used with TLS versions 1.2, 1.1, or 1.0:

TLS 1.2 servers that are configured with RSA certificates may be configured to support the following cipher suites:

TLS servers may be configured to support the following cipher suites when RSA certificates are used with TLS versions 1.2, 1.1, or 1.0:

TLS 1.2 servers that are configured with DSA certificates may be configured to support the following cipher suites:

TLS servers may be configured to support the following cipher suites when DSA certificates are used with TLS versions 1.2, 1.1, or 1.0:

DH certificates contain a static key and are signed using either DSA or RSA. Unlike cipher suites that use ephemeral DH, these cipher suites contain static DH parameters. While the use of static keys is technically acceptable, the use of ephemeral key cipher suites is encouraged and preferred over the use of the cipher suites listed in this section.

TLS 1.2 servers that are configured with DSA-signed DH certificates may be configured to support the following cipher suites:

TLS servers may be configured to support the following cipher suites when DSA-signed DH certificates are used with TLS versions 1.2, 1.1, or 1.0:

TLS 1.2 servers that are configured with RSA-signed DH certificates may be configured to support the following cipher suites:

TLS servers may be configured to support the following cipher suites when RSA-signed DH certificates are used with TLS versions 1.2, 1.1, or 1.0:

ECDH certificates contain a static key and are signed using either ECDSA or RSA. Unlike cipher suites that use ephemeral ECDH, these cipher suites contain static ECDH parameters. The use of ephemeral key cipher suites is encouraged and preferred over the use of the cipher suites listed in this section.

TLS 1.2 servers that are configured with ECDSA-signed ECDH certificates may be configured to support the following cipher suites:

TLS servers may be configured to support the following cipher suites when ECDSA-signed ECDH certificates are used with TLS versions 1.2, 1.1, or 1.0:

TLS 1.2 servers that are configured with RSA-signed ECDH certificates may be configured to support the following cipher suites:

TLS servers may be configured to support the following cipher suites when RSA-signed ECDH certificates are used with TLS versions 1.2, 1.1, or 1.0:

TLS 1.3 servers may be configured to support the following cipher suites:

These cipher suites may be used with either RSA or ECDSA server certificates; DSA and DH certificates are not supported by TLS 1.3. These cipher suites may also be used with pre-shared keys, as specified in Appendix C.

System administrators need to fully understand the ramifications of selecting cipher suites and configuring applications to support only those cipher suites. The security guarantees of the cryptography are limited to the weakest cipher suite supported by the configuration. When configuring an implementation, there are several factors that affect the selection of supported cipher suites.

RFC 4346 [24] describes timing attacks on CBC cipher suites, as well as mitigation techniques. TLS implementations shall use the bad_record_mac error to indicate a padding error when communications are secured using a CBC cipher suite. Implementations shall compute the MAC regardless of whether padding errors exist.

In addition to the CBC attacks addressed in RFC 4346 [24], the Lucky 13 attack [1] demonstrates that a constant-time decryption routine is also needed to prevent timing attacks. TLS implementations should support constant-time decryption or near constant-time decryption.

The POODLE attack exploits nondeterministic padding in SSL 3.0 [43]. The vulnerability does not exist in the TLS protocols, but the vulnerability can exist in a TLS implementation when the SSL decoder code is reused to process TLS data [38]. TLS implementations shall correctly decode the CBC padding bytes.

Note that CBC-based attacks can be prevented by using AEAD cipher suites (e.g., GCM, CCM), which are supported in TLS 1.2.

Many TLS servers and clients support cipher suites that are not composed of only NIST-approved algorithms. Therefore, it is important that the server is configured to only use NIST-recommended cipher suites. This is particularly important for server implementations that do not allow the server administrator to specify preference order. In such servers, the only way to ensure that a server uses NIST-approved algorithms is to disable cipher suites that use other algorithms.

If the server implementation does allow the server administrator to specify a preference, the system administrator is encouraged to use the preference recommendations listed in Section 3.3.1.1.

The cryptographic module used by the server shall be a FIPS 140-validated cryptographic module [50, 51]. All cryptographic algorithms that are included in the configured cipher suites and the random number generator shall be within the scope of the validation.

Note that the TLS 1.0 and 1.1 pseudorandom function (PRF) uses MD5 and SHA-1 in parallel so that if one hash function is broken, security is not compromised. While MD5 is not a NIST-approved algorithm, the PRF is specified as acceptable in SP 800-135 [21]. In TLS 1.2, the default hash function in the PRF is SHA-256. TLS 1.3 replaces the PRF with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF), described in RFC 5869 [37].

Also note that in TLS versions prior to 1.2, the use of SHA-1 is considered acceptable for signing ephemeral keys and for client authentication using digital signatures. This is due to the difficulty for a third party to cause a collision that is not detected.

Other than the SHA-1 exception listed for specific instances above, all cryptography used shall provide at least 112 bits of security. All server and client certificates shall contain public keys that offer at least 112 bits of security. All server and client certificates and certificates in their certification paths shall be signed using key pairs that offer at least 112 bits of security and SHA-224 or a stronger hashing algorithm. All ephemeral keys used by the client and server shall offer at least 112 bits of security. All symmetric algorithms used to protect the TLS data shall use keys that offer at least 112 bits of security.

The FIPS 140 validation certificate for the cryptographic module used by the server shall indicate that the random bit generator (RBG) has been validated in accordance with the SP 800-90 series [8, 48, 66].²²

The server random value, sent in the ServerHello message, contains a 4-byte timestamp²³ value and 28-byte random value in TLS versions 1.0, 1.1, and 1.2, and contains a 32-byte random value in TLS 1.3. The validated random number generator shall be used to generate the random bytes of the server random value.²⁴ The validated random number generator should be used to generate the 4-byte timestamp of the server random value.

Several TLS extensions are described in RFCs. This section contains recommendations for a subset of the TLS extensions that the federal agencies shall, should, or should not use as they become prevalent in commercially available TLS servers and clients.

System administrators must carefully consider the risks of supporting extensions that are not listed as mandatory. Only extensions whose specifications have an impact on security are discussed here, but the reader is advised that supporting any extension can have unintended security consequences. In particular, enabling extensions increases the potential for implementation flaws and could leave a system vulnerable. For example, the Heartbleed bug [70] was a flaw in an implementation of the heartbeat extension [64]. Although the extension has no inherent security implications, the implementation flaw exposed server data, including private keys, to attackers.

In general, servers should only be configured to support extensions that are required by the application or that enhance security. Extensions that are not needed should not be enabled.

The server shall support the use of the following TLS extensions.

Applies to TLS versions: 1.0, 1.1, 1.2

In TLS versions 1.0 to 1.2, session renegotiation is vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of its choice, and then splices in a new TLS connection from a legitimate client. The server treats the legitimate client’s initial TLS handshake as a renegotiation of the attacker’s negotiated session and thus believes that the initial data transmitted by the attacker is from the legitimate client. The session renegotiation extension is defined to prevent such a session splicing or session interception. The extension uses the concept of cryptographically binding the initial session negotiation and session renegotiation.

Server implementations shall perform initial and subsequent renegotiations in accordance with RFC 5746 [59] and RFC 8446 [57].

Applies to TLS versions: 1.0, 1.1, 1.2, 1.3

Multiple virtual servers may exist at the same network address. The server name indication extension allows the client to specify which of the servers located at the address it is trying to connect with. This extension is available in all versions of TLS. The server shall be able to process and respond to the server name indication extension received in a ClientHello message as described in [29].

Applies to TLS versions: 1.0, 1.1, 1.2

Bhargavan et al. have shown that an active attacker can synchronize two TLS sessions such that they share the same master secret, thus allowing the attacker to perform a man-in-the-middle attack [12]. The Extended Master Secret extension, specified in RFC 7627 [13], prevents such attacks by binding the master secret to a hashed log of the full handshake. The server shall support the use of this extension.

Applies to TLS versions: 1.2, 1.3

Servers shall support the processing of the signature algorithms extension received in a ClientHello message. The extension, its syntax, and processing rules are described in Sections 7.4.1.4.1, 7.4.2, and 7.4.3 of RFC 5246 [25] and Section 4.2.3 of RFC 8446 [57]. Note that the extension described in RFC 8446 updates the extension described in RFC 5246 by adding an additional signature scheme.

Applies to TLS versions: 1.0, 1.1, 1.2, 1.3

When the client wishes to receive the revocation status of the TLS server certificate from the TLS server, the client includes the Certificate Status Request (status_request) extension in the ClientHello message. Upon receipt of the status_request extension, a server with a certificate issued by a CA that supports OCSP shall include the certificate status along with its certificate by sending a CertificateStatus message immediately following the Certificate message.²⁵ While the extension itself is extensible, only OCSP-type certificate status is defined in [29]. This extension is also called OCSP stapling.

Support the use of the following TLS extensions under the circumstances described in the following subsections:

Applies to TLS versions: 1.0, 1.1, 1.2

TLS 1.3 includes a downgrade protection mechanism that previous versions do not. In versions prior to TLS 1.3, an attacker can use an external version negotiation as a means to force unnecessary protocol downgrades on a connection. In particular, the attacker can make it appear that the connection failed with the requested TLS version, and some client implementations will try the connection again with a downgraded protocol version. This cipher suite value, described in RFC 7507 [42], provides a mechanism to prevent unintended protocol downgrades in versions prior to TLS 1.3. Clients signal when a connection is a fallback, and if the server deems it inappropriate (i.e., the server supports a higher TLS version), the server returns a fatal alert.

When TLS versions prior to TLS 1.2 are supported by the server and TLS version 1.3 is not supported, the fallback SCSV shall be supported.

Applies to TLS versions: 1.0, 1.1, 1.2, 1.3

The Supported Groups extension (supported_groups) allows the client to indicate the domain parameter groups that it supports to the server. The extension was originally called the Supported Elliptic Curves extension (elliptic_curves) and was only used for elliptic curve groups, but it may now also be used to negotiate finite field groups. In TLS 1.3, the Supported Groups extension must be used to negotiate both elliptic curve and finite field groups. Servers that support either ephemeral ECDH cipher suites or TLS 1.3 shall support this extension. When elliptic curve cipher suites are configured, at least one of the NIST-approved curves, P-256 (secp256r1) and P-384 (secp384r1), shall be supported as described in RFC 8422 [52]. Additional NIST-recommended elliptic curves are listed in SP 800-56A, Appendix D [6]. Finite field groups that are approved for TLS in SP 800-56A, Appendix D may be supported.

Applies to TLS version 1.3

The Key Share extension is used in TLS 1.3 to send cryptographic parameters. Servers that support TLS 1.3 shall support this extension as described in Section 4.2.7 of RFC 8446 [57].

Applies to TLS versions: 1.0, 1.1, 1.2

Servers that support EC cipher suites with TLS 1.2 and below shall be able to process the supported point format received in the ClientHello message by the client. The servers shall process this extension in accordance with Section 5.1 of RFC 8422 [52].

Servers that support EC cipher suites shall also be able to send the supported EC point format in the ServerHello message as described in Section 5.2 of RFC 8422 [52].

Applies to TLS versions: 1.0, 1.1, 1.2

The multiple certificate status extension improves on the Certificate Status Request extension described in Section 3.4.1.5 by allowing the client to request the status of all certificates provided by the server in the TLS handshake. When the server returns the revocation status of all the certificates in the server certificate chain, the client does not need to query any revocation service providers, such as OCSP responders. This extension is documented in RFC 6961 [54]. Servers that have this capability and have certificates issued by CAs that support OCSP should be configured to support this extension.

Applies to TLS versions: 1.0, 1.1, 1.2

The trusted CA indication (trusted_ca_keys) extension allows a client to specify which CA root keys it possesses. This is useful for sessions where the client is memory-constrained and possesses a small number of root CA keys. Servers that communicate with memory-constrained clients and that have been issued certificates by multiple CAs shall be able to process and respond to the trusted CA indication extension received in a ClientHello message as described in [29].

Applies to TLS versions: 1.0, 1.1, 1.2

Several attacks on CBC cipher suites have been possible due to the MAC-then-encrypt order of operations used in TLS versions 1.0, 1.1, and 1.2. The Encrypt-then-MAC extension alters the order that the encryption and MAC operations are applied to the data. This is believed to provide stronger security and mitigate or prevent several known attacks on CBC cipher suites. Servers that are configured to negotiate CBC cipher suites shall support this extension as described in [33].

Applies to TLS versions: 1.0, 1.1, 1.2

The Truncated HMAC extension allows a truncation of the HMAC output to 80 bits for use as a MAC tag. An 80-bit MAC tag complies with the recommendations in SP 800-107 [20] but reduces the security provided by the integrity algorithm. Because forging a MAC tag is an online attack, and the TLS session will terminate immediately when an invalid MAC tag is encountered, the risk introduced by using this extension is low. However, truncated MAC tags shall not be used in conjunction with variable-length padding due to attacks described by Paterson et al. [53]. This extension is only applicable when cipher suites that use CBC modes are supported.

Applies to TLS version 1.3

The Pre-Shared Key (PSK) extension (pre_shared_key), available in TLS 1.3, is used to indicate the identity of the pre-shared key to be used for PSK key establishment. In TLS 1.3 pre-shared keys may either be established out-of-band, as in TLS 1.2 or below, or in a previous connection, in which case they are used for session resumption. Servers that support TLS 1.3 may be configured to support this extension in order to support session resumption or to support the use of pre-shared keys that are established out-of-band.

Applies to TLS version 1.3

A TLS 1.3 client must send the Pre-Shared Key Exchange Modes extension (psk_key_exchange_modes) if it sends the Pre-Shared Key extension. TLS 1.3 servers use the list of key exchange modes present in the extension to select an appropriate key exchange method. TLS servers that support TLS 1.3 and the Pre-Shared Key extension shall support this extension.

Applies to TLS version 1.3

The supported versions extension is sent in the ClientHello message to indicate which versions of TLS the client supports. A TLS 1.3 server shall be able to process this extension. When it is absent from the ClientHello message, the server shall use the version negotiation specified in TLS 1.2 and earlier.

Applies to TLS version 1.3

The cookie extension allows the server to force the client to prove that it is reachable at its apparent network address and offload state information to the client. Servers that support TLS 1.3 may support the cookie extension in accordance with RFC 8446 [57].

Applies to TLS versions: 1.2, 1.3

The Certificate Signature Algorithms extension (signature_algorithms_cert) indicates the signature algorithms that may be used in certificates. (When it is not present, algorithms in the Signature Algorithms extension apply to certificates as well.) TLS servers that support TLS 1.3 shall support this extension, and it should be supported for TLS 1.2.

Applies to TLS version 1.3

The Post-handshake Client Authentication extension (post_handshake_auth) allows the server to request client authentication after the handshake is complete. TLS servers that support TLS 1.3 may support this extension.

Applies to TLS versions: 1.0, 1.1, 1.2, 1.3

The Certificate Transparency project (described in RFC 6962 [40]) strives to reduce the impact of certificate-based threats by making the issuance of CA-signed certificates more transparent. This is done through the use of public logs of certificates, public log monitoring, and public certificate auditing. Certificate logs are cryptographically assured records of certificates that are open to public scrutiny. Certificates may be appended to logs, but they cannot be removed, modified, or inserted into the middle of a log. Monitors watch certificate logs for suspicious certificates, such as those that were not authorized by the domain they claim to represent. Auditors have the ability to check the membership of a particular certificate in a log, as well as verify the integrity and consistency of logs.

Evidence that the server’s certificate has been submitted to Certificate Transparency logs may be provided to clients either in the certificate itself or in a Signed Certificate Timestamps TLS extension (signed_certificate_timestamp). Servers with certificates issued by publicly trusted CAs that do not include a Signed Certificate Timestamps List extension should support the Signed Certificate Timestamps TLS extension.

The following extensions should not be used:

The Raw Public Keys extension shall not be supported.

Applies to TLS versions: 1.0, 1.1, 1.2

The Client Certificate URL extension allows a client to send a URL pointing to a certificate rather than sending a certificate to the server during mutual authentication. This can be very useful for mutual authentication with constrained clients. However, this extension can be used for malicious purposes. The URL could belong to an innocent server on which the client would like to perform a denial of service attack, turning the TLS server into an attacker. A server that supports this extension also acts as a client while retrieving a certificate and, therefore, becomes subject to additional security concerns. For these reasons, the Client Certificate URL extension should not be supported. However, if an agency determines that the risks are minimal and this extension is needed for environments where clients are in constrained devices, the extension may be supported. If the client certificate URL extension is supported, the server shall be configured to mitigate the security concerns described above and in Section 11.3 of [29].

Applies to TLS version 1.3

The Early Data Indication extension (early_data) allows the client to send application data in the ClientHello message when pre-shared keys are used. This includes pre-shared keys that are established out-of-band as well as those used for session resumption. TLS does not protect this early data against replay attacks. Servers should not process early data received in the ClientHello message. If the server is configured to send the Early Data Indication extension, the server shall use methods of replay protection, such as those described in Section 8 of RFC 8446 [57]. See Section 3.6 for more information on early data (also called 0-RTT data).

Applies to TLS versions: 1.0, 1.1, 1.2, 1.3

The Raw Public Keys extension, described in RFC 7250 [71], provides an alternative to certificate-based authentication that only uses the information contained in the SubjectPublicKeyInfo field in an X.509 version 3 certificate. While this reduces the size of the public key structure and simplifies processing, it removes any assurances that a public key belongs to a particular entity. To provide authentication when using this extension, an out-of-band binding between a public key and entity must be used.

Where strong cryptographic client authentication is required, TLS servers may use the TLS protocol client authentication option to request a certificate from the client to cryptographically authenticate the client.²⁶ For example, the Personal Identity Verification (PIV) Authentication certificate [47] (and the associated private key) provides a suitable option for strong authentication of federal employees and contractors. To ensure that agencies are positioned to take full advantage of the PIV Card, all TLS servers that perform client authentication shall implement certificate-based client authentication.

The client authentication option requires the server to implement the X.509 path validation mechanism and a trust anchor store. Requirements for these mechanisms are specified in Sections 3.5.1 and 3.5.2, respectively. To ensure that cryptographic authentication actually results in strong authentication, client keys shall be capable of providing at least 112 bits of security. Section 3.5.3 describes mechanisms that can contribute, albeit indirectly, to enforcing this requirement. Section 3.5.4 describes the client’s use of the server hints list.

The TLS server shall be configurable to terminate the connection with a fatal “handshake failure” alert when a client certificate is requested and the client does not have a suitable certificate.

The client certificate shall be validated in accordance with the certification path validation rules specified in Section 6 of [19]. In addition, the revocation status of each certificate in the certification path shall be validated using the Online Certificate Status Protocol (OCSP) or a certificate revocation list (CRL). OCSP checking shall be in compliance with RFC 6960 [63].

Revocation information shall be obtained as described in Section 3.2.2.

The server shall be able to determine the certificate policies that the client certificate is trusted for by using the certification path validation rules specified in Section 6 of RFC 5280 [19]. Server and back-end applications may use this determination to accept or reject the certificate. Checking certificate policies assures the server that only client certificates that have been issued with acceptable assurance, in terms of CA and registration system and process security, are accepted.

Not all commercial products may support the public-key certification path validation and certificate policy processing rules listed and cited above. When implementing client authentication, federal agencies shall either use the commercial products that meet these requirements or augment commercial products to meet these requirements.

The server shall be able to provide the client certificate and the certificate policies for which the client certification path is valid to consuming applications in order to support access control decisions.

Having an excessive number of trust anchors installed in the TLS application can expose the application to all the PKIs emanating from those trust anchors. The best way to minimize the exposure is to only include the trust anchors in the trust anchor store that are absolutely necessary for client public-key certificate authentication.

The server shall be configured only with trust anchors that the system owner trusts and, of those, only the ones that are required to authenticate the clients in the case where the server supports client authentication in TLS. System administrators of a TLS server that supports certificate-based client authentication shall perform an analysis of the client certificate issuers and use that information to determine the minimum set of trust anchors required for the server. These trust anchors are typically a small subset of the trust anchors that may be included on the server by default. Also, note that this trust anchor store is distinct from the machine trust anchor store. Thus, the default set of trust anchors shall be examined to determine if any of them are required for client authentication. Some specific enterprise and/or PKI service trust anchors may need to be added.

In the U.S. Federal Government environment, in most situations, the Federal Common Policy Root or the agency root (if cross-certified with the Federal Bridge Certification Authority or the Federal Common Policy Root) should be sufficient to build a certification path to the client certificates.

The only direct mechanism for a server to check whether the key size and algorithms presented in a client public-key certificate are acceptable is for the server to examine the public key and algorithm in the client’s certificate. An indirect mechanism is to check that the certificate policies extension in the client public-key certificate indicates the minimum cryptographic strength of the signature and hashing algorithms used and for the server to perform certificate policy processing and checking. The server shall check the client key length if client authentication is performed and the server implementation provides a mechanism to do so. Federal agencies shall use the key size guidelines provided in SP 800-131A [10] to check the client key size.

Clients may use the list of trust anchors sent by the server in the CertificateRequest message to determine if the client’s certification path terminates at one of these trust anchors. The list sent by the server is known as a “hints list.” When the server and client are in different PKI domains and the trust is established via direct cross-certification between the two PKI domains (i.e., the server PKI domain and the client PKI domain) or via transitive cross-certification (i.e., through cross-certifications among multiple PKI domains), the client may erroneously decide that its certificate will not be accepted by the server since the client’s trust anchor is not sent in the hints list. To mitigate this failure, the server shall either: 1) maintain the trust anchors of the various PKIs whose subscribers are the potential clients for the server and include them in the hints list or 2) be configured to send an empty hints list so that the client can always provide a certificate it possesses. The hints list shall be distinct from the server’s trust anchor store.²⁷ In other words, the server shall continue to only populate its trust anchor store with the trust anchor of the server’s PKI domain and the domains it needs to trust directly for client authentication. Note that the distinction between the server hints list and the server’s own trust store is as follows: 1) the hints list is the list of trust anchors that a potential client might trust, and 2) the server’s trust store is the list of trust anchors that the server explicitly trusts.

Previous TLS sessions can be resumed, allowing for a connection to be established using an abbreviated handshake. All versions of TLS offer session resumption, although the mechanism for performing resumption differs. A server may be configured to ignore requests to resume a session if the implementation allows it.

Additional mechanisms have been developed for session resumption, such as the Stateless TLS Session Resumption extension [62]. While these guidelines neither encourage nor discourage the use of such mechanisms, it is important to understand the security impact if long-term or shared keys are compromised. If resumption is allowed, frequent key replacement and short lifetimes for resumption information are recommended, as applicable. See [67] for discussion on the security impacts of resumption mechanisms.

TLS 1.3 allows the client to send data (known as 0-RTT data) in the first flight of a handshake. This practice may provide opportunities for attackers, such as replay attacks.²⁸ The TLS 1.3 specification describes two mechanisms to mitigate threats introduced by 0-RTT data. One of these mechanisms is single-use tickets, which allows each session ticket to be used only once. It may be difficult to implement this mechanism in an environment with distributed servers as a session database must be shared between servers. ClientHello recording is a second mechanism that defends against replay attacks by recording a unique value derived from the ClientHello and rejecting duplicates. To limit the size of the list, the server can maintain a list only within a specified time window. In general, 0-RTT data should not be accepted by the server. If the server does allow 0-RTT data, then the server should use the single-use ticket mechanism in accordance with RFC 8446 (see Section 8 of [57]).

The use of compression may enable attackers to perform attacks using compression-based side channels (e.g., [60], [11]). To defend against these attacks, the null compression method shall be enabled, and all other compression methods shall be disabled.

The sections above specify TLS-specific functionality. This functionality is necessary but is not sufficient to achieve security in an operational environment.

Federal agencies shall ensure that TLS servers include appropriate network security protections as specified in other NIST guidelines, such as SP 800-53 [36].

The server shall operate on a secure operating system.²⁹ Where the server relies on a FIPS 140 Level 1 cryptographic module, the software and private key shall be protected using the operating system identification, authentication, and access control mechanisms. In some highly sensitive applications, server private keys may require protection using a FIPS 140 Level 2 or higher hardware cryptographic module.

The server and associated platform shall be kept up-to-date in terms of security patches. This is critical to various aspects of security.

This section provides a minimum set of requirements that a TLS client must meet in order to adhere to these guidelines. Requirements are organized as follows: TLS protocol version support, client keys and certificates, cryptographic support, TLS extension support, server authentication, session resumption, compression methods, and operational considerations.

Specific requirements are stated as either implementation requirements or configuration requirements. Implementation requirements indicate that federal agencies shall not procure TLS client implementations unless they include the required functionality. Configuration requirements indicate that system administrators are required to verify that particular features are enabled or, in some cases, configured appropriately if present.

The client shall be configured to use TLS 1.2 and should be configured to use TLS 1.3. The client may be configured to use TLS 1.1 and TLS 1.0 to facilitate communication with private sector servers. The client shall not be configured to use SSL 2.0 or SSL 3.0. Agencies shall support TLS 1.3 by January 1, 2024. After this date, clients shall be configured to use TLS 1.3. In general, clients that support TLS 1.3 should be configured to use TLS 1.2 as well. However, TLS 1.2 may be disabled on clients that support TLS 1.3 if TLS 1.2 is not needed for interoperability.

Some applications may require client authentication. For TLS, this can be achieved by performing mutual authentication using certificates.

When certificate-based client authentication is needed, the client shall be configured with a certificate that adheres to the recommendations presented in this section. A client certificate may be configured on the system or located on an external device (e.g., a PIV Card). For this specification, the TLS client certificate shall be an X.509 version 3 certificate; both the public key contained in the certificate and the signature shall provide at least 112 bits of security. If the client supports TLS versions prior to TLS 1.2, the certificate should be signed with an algorithm that is consistent with the public key:³⁰

The client certificate profile is listed in Table 4-1. In the absence of an agency-specific client certificate profile, this profile should be used for client certificates.

Table 4-1: TLS Client Certificate Profile

If a client has multiple certificates that meet the requirements of the TLS server, the TLS client (e.g., a browser) may ask the user to select from a list of certificates. The extended key usage (EKU) extension limits the operations for which the keys in a certificate may be used, and so the use of the EKU extension in client certificates may eliminate this request. If the EKU extension is included in client certificates, then the id-kp-client-auth key purpose OID should be included in the certificates to be used for TLS client authentication and should be omitted from any other certificates.

Client certificates are also filtered by TLS clients on the basis of an ability to build a path to one of the trust anchors in the hints list sent by the server as described in Section 3.5.4.

The client shall perform revocation checking of the server certificate. Revocation information can be obtained by the client from one of the following locations:

When the server does not provide the revocation status, the local certificate store does not have the current or a cogent CRL or OCSP response, and the OCSP responder and the CRL distribution point are unavailable or inaccessible at the time of TLS session establishment, the client will either terminate the connection or accept a potentially revoked or compromised certificate. The decision to accept or reject a certificate in this situation should be made according to agency policy.

The client public-key certificate may be trusted by the servers on the basis of the policies, procedures, and security controls used to issue the client public-key certificate as described in Section 3.5.1. For example, these guidelines recommend that the PIV Authentication certificate be the norm for authentication of federal employees and long-term contractors. PIV Authentication certificate policy is defined in the Federal PKI Common Policy Framework [31], and PIV-I Authentication certificate policy is defined in the X.509 Certificate Policy for the Federal Bridge Certification Authority [68]. Depending on the requirements of the server-side application, other certificate policies may also be acceptable. Guidance regarding other certificate policies is outside the scope of these guidelines.

The acceptable cipher suites for a TLS client are the same as those for a TLS server. General-purpose cipher suites are listed in Section 3.3.1. Cipher suites appropriate for pre-shared key environments for TLS 1.2 and prior versions are listed in Appendix C. Applications that require RSA key transport as the key exchange method may use cipher suites listed in Appendix D during the deprecation period. When ephemeral keys are used to establish the master secret, each ephemeral key-pair (i.e., the server ephemeral key-pair and the client ephemeral key-pair) shall have at least 112 bits of security.

The client should not be configured to use cipher suites other than those listed in Section 3.3.1, Appendix C, or Appendix D.32

To mitigate attacks against CBC mode, TLS implementations that support versions prior to TLS 1.3 shall use the bad_record_mac error to indicate a padding error. Implementations shall compute the MAC regardless of whether padding errors exist. TLS implementations should support constant-time decryption or near constant-time decryption. This does not apply to TLS 1.3 implementations as they do not support cipher suites that use CBC mode.

The client shall use validated cryptography as described for the server in Section 3.3.3.

The validated random number generator shall be used to generate the random bytes (32 bytes in TLS 1.3; 28 bytes in prior TLS versions) of the client random value. The validated random number generator should be used to generate the 4-byte timestamp of the client random value for TLS versions prior to TLS 1.3.

In general, it is advised that clients only be configured to support extensions that are required for interoperability or enhance security. Extensions that are not needed should not be enabled.

The client shall be configured to use the following extensions:

Applies to TLS versions: 1.0, 1.1, 1.2

The Renegotiation Indication extension is required by these guidelines as described in Section 3.4.1.1. Clients shall perform the initial and subsequent renegotiations in accordance with RFC 5746 [59].

Applies to TLS versions: 1.0, 1.1, 1.2, 1.3

The server name indication extension is described in Section 3.4.1.2. The client shall be capable of including this extension in a ClientHello message as described in RFC 6066 [29].

Applies to TLS versions: 1.0, 1.1, 1.2

The Extended Master Secret extension described in Section 3.4.1.3 prevents man-in-the-middle attacks by binding the master secret to a hashed log of the full handshake. The client shall support this extension.

Applies to TLS versions: 1.2, 1.3

The clients shall assert acceptable hashing and signature algorithm pairs in this extension in TLS 1.2 and TLS 1.3 ClientHello messages. The extension, its syntax, and processing rules are described in Sections 7.4.1.4.1, 7.4.4, 7.4.6 and 7.4.8 of RFC 5246 [25] and in Section 4.2.3 of RFC 8446 [57]. Note that the extension described in RFC 8446 updates the extension described in RFC 5246 by adding an additional signature scheme.

Applies to TLS versions: 1.0, 1.1, 1.2, 1.3

The client shall include the “status_request” extension in the ClientHello message.

A TLS client supports the following TLS extensions under the circumstances described:

Applies to TLS versions: 1.0, 1.1, 1.2

The cipher suite value described in Section 3.4.2.1 provides a mechanism to prevent unintended protocol downgrades in TLS versions prior to TLS 1.3. Clients signal when a connection is a fallback, and if the server supports a higher TLS version, the server returns a fatal alert. If the client does not support TLS 1.3 and is attempting to connect with a TLS version prior to TLS 1.2, the client shall include TLS_FALLBACK_SCSV at the end of the cipher suite list in the ClientHello message.

Applies to TLS versions: 1.0, 1.1, 1.2, 1.3

The Supported Groups extension (supported_groups) is described in Section 3.4.2.2. Client implementations shall send this extension in TLS 1.3 ClientHello messages and in ClientHello messages that include ephemeral ECDH cipher suites. When elliptic curve cipher suites are configured, at least one of the NIST-approved curves, P-256 (secp256r1) and P-384 (secp384r1), shall be supported as described in RFC 8422 [52]. Additional NIST-recommended elliptic curves are listed in SP 800-56A, Appendix D [6]. Finite field groups that are approved for TLS in SP 800-56A, Appendix D may be supported.

Applies to TLS version 1.3

The Key Share extension is used to send cryptographic parameters. Clients that support TLS 1.3 shall support this extension as described in Section 4.2.7 of RFC 8446 [57].

Applies to TLS versions: 1.0, 1.1, 1.2

The clients that support EC cipher suites with TLS 1.2 and below shall be capable of specifying supported point formats in the ClientHello message in accordance with Section 5.1 of [52].

Clients that support EC cipher suites shall support the processing of at least one³³ of the EC point formats received in the ServerHello message as described in Section 5.2 of [52].

Applies to TLS versions: 1.0, 1.1, 1.2

The multiple certificate status extension is described in Section 3.4.2.5. This extension improves on the Certificate Status Request extension described in Section 3.4.1.5 by allowing the client to request the status of all certificates provided by the server in the TLS handshake. This extension is documented in RFC 6961 [54]. Client implementations that have this capability should be configured to include this extension in the ClientHello message.

Applies to TLS versions: 1.0, 1.1, 1.2

Clients that run on memory-constrained devices where only a small number of CA root keys are stored should be capable of including the trusted CA indication (trusted_ca_keys) extension in a ClientHello message as described in [29].

Applies to TLS versions: 1.0, 1.1, 1.2

The Encrypt-then-MAC extension described in Section 3.4.2.7 can mitigate or prevent several known attacks on CBC cipher suites. In order for this modified order of operations to be applied, both the server and client need to implement the Encrypt-then-MAC extension and negotiate its use. When CBC mode cipher suites are configured, clients shall support this extension as described in RFC 7366 [33]. The client shall include this extension in the ClientHello message whenever the ClientHello message includes CBC cipher suites.

Applies to TLS versions: 1.0, 1.1, 1.2

The Truncated HMAC extension is described in Section 3.4.2.8. Clients running on constrained devices may support this extension. The Truncated HMAC extension shall not be used in conjunction with variable-length padding due to attacks described by Paterson et al. [53]. This extension is only applicable when cipher suites that use CBC modes are supported.

Applies to TLS version 1.3

The Pre-Shared Key extension (pre_shared_key) is used to indicate the identity of the pre-shared key to be used for PSK key establishment. In TLS 1.3, pre-shared keys may either be established out-of-band, as in TLS 1.2 and prior versions, or in a previous connection, in which case they are used for session resumption. Clients that support TLS 1.3 may be configured to use this extension in order to allow session resumption or to allow the use of pre-shared keys that are established out-of-band.

Applies to TLS version 1.3

A TLS 1.3 client must send the Pre-Shared Key Exchange Modes extension (psk_key_exchange_modes) if it sends the Pre-Shared Key extension. Otherwise, the server will abort the handshake. TLS clients that support TLS 1.3 and the Pre-Shared Key extension shall implement this extension.

Applies to TLS version 1.3

The supported versions extension indicates which versions of TLS the client is able to negotiate. A TLS 1.3 client shall send this extension in the ClientHello message.

Applies to TLS version 1.3

The cookie extension allows the server to force the client to prove that it is reachable at its apparent network address and offload state to the client. Clients that support TLS 1.3 shall support the cookie extension in accordance with RFC 8446 [57].

Applies to TLS versions: 1.2, 1.3

The Certificate Signature Algorithms extension (signature_algorithms_cert) indicates the signature algorithms that may be used in certificates. This allows the entity requesting a certificate (client or server) to request different signature algorithms for the certificate than for the TLS handshake. A client may send this extension to the server and may receive this extension from a server that is requesting certificate-based client authentication. This extension does not need to be sent if the algorithms in the Signature Algorithms extension apply to certificates as well. TLS client implementations that support TLS 1.3 shall support this extension, and it should be supported for TLS 1.2.

Applies to TLS version 1.3

The client sends the Post-handshake Client Authentication extension (post_handshake_auth) to indicate that it is willing to respond to client authentication requests after the handshake is complete. TLS clients that support TLS 1.3 may support this extension.

The following extensions should not be used:

The Raw Public Key extension shall not be supported.

The reasons for discouraging the use of these extensions can be found in Section 3.4.3.

The client shall be able to build the certification path for the server certificate presented in the TLS handshake with at least one of the trust anchors in the client trust store if an appropriate trust anchor is present in the store. The client may use all or a subset of the following resources to build the certification path: the local certificate store, certificates received from the server during the handshake, Lightweight Directory Access Protocol (LDAP), the resources declared in the CA Repository field of the Subject Information Access extension in various CA certificates, and the resources declared in the CA Issuers field of the Authority Information Access extension in various certificates.

The client shall validate the server certificate in accordance with the certification path validation rules specified in Section 6 of [19]. The revocation status of each certificate in the certification path shall be checked using the Online Certificate Status Protocol (OCSP) or a certificate revocation list (CRL). OCSP checking shall be in compliance with [63]. Revocation information shall be obtained as described in Section 4.2.2.

Not all clients support name constraint checking. Federal agencies should only procure clients that perform name constraint checking in order to obtain assurance that unauthorized certificates are properly rejected.

The client shall terminate the TLS connection if path validation fails.

Federal agencies shall only use clients that check that the DNS name or IP address (whichever is presented in the client TLS request) matches a DNS name or IP address contained in the server certificate. The client shall terminate the TLS connection if the name check fails.

Having an excessive number of trust anchors installed in the TLS client can increase the chances for the client to be spoofed. As the number of trust anchors increase, the number of CAs that the client trusts increases, and the chances that one of these CAs or its registration system or process will be compromised to issue TLS server certificates also increases.

Clients shall not overpopulate their trust stores with various CA certificates that can be verified via cross-certification.³⁴ Direct trust of these certificates can expose the clients unduly to a variety of situations including, but not limited to, revocation or compromise of these trust anchors. Direct trust also increases the operational and security burden on the clients to promulgate the addition and deletion of trust anchors. Instead, the client shall rely on the server overpopulating or not providing the hints list to mitigate the client certificate selection and path-building problem as discussed in Section 3.5.4.

The only direct mechanism for a client to check if the key size presented in a server public certificate is acceptable is for the client to examine the server public key in the certificate. An indirect mechanism is to ensure that the server public-key certificate was issued under a policy that indicates the minimum cryptographic strength of the signature and hashing algorithms used. In some cases, this can be done by the client performing certificate policy processing and checking. However, since many TLS clients cannot be configured to accept or reject certificates based on the policies under which they were issued, this may require ensuring that the trust anchor store only contains trust anchors for CAs that issue certificates under acceptable policies. The client shall check the server public key length if the client implementation provides a mechanism to do so. The client shall also check the server public key length if the server uses ephemeral keys for the creation of the master secret and the client implementation provides a mechanism to do so.

The length of each write key is determined by the negotiated cipher suite. Restrictions on the length of the shared session keys can be enforced by configuring the client to only support cipher suites that meet the key length requirements.

When the TLS client is a browser, the browser interface can be used to determine if a TLS session is in effect. The indication that a TLS session is in effect varies by browser. Examples of indicators include a padlock in the URL bar, the word “secure” preceding the URL, or a different color for the URL bar. Some clients, such as browsers, may allow further investigation of the server certificate and negotiated session parameters by clicking on the lock (or other indicator). Users should examine the interface for the presence of the indicator to ensure that the TLS session is in force and should also visually examine website URLs to ensure that the user intended to visit the indicated website. Users should be aware that URLs can appear to be legitimate but still not be valid. For example, the numeric “1” and the letter “l” appear quite similar or the same to the human eye.

Client authentication keys may be located outside of the client (e.g., in PIV Cards). Users shall follow the relevant policies and procedures for protecting client authentication keys outside of the client.

Session resumption considerations and server recommendations were given in Section 3.6. There are no specific recommendations for clients regarding session resumption when using TLS 1.2, 1.1, or 1.0. Clients typically will not know if any anti-replay mechanisms are in place to prevent replay attacks on 0-RTT data in TLS 1.3. Therefore, clients using TLS 1.3 should not send 0-RTT data.

RFC 7918 [39] describes a technique called False Start that allows a TLS 1.2 client to send early data. While this concept is similar to the 0-RTT data of TLS 1.3, there are differences that affect security. For example, an attacker may perform downgrade attacks, both of protocol versions and cipher suites, and obtain client data before the handshake is determined to be invalid. While RFC 7918 provides recommendations for improving security, it is safest to disable False Start unless there is a real need for it. TLS 1.2 clients shall not use False Start.

The client shall follow the same compression recommendations as the server, which are described in Section 3.7.

The client and associated platform shall be kept up-to-date in terms of security patches. This is critical to various aspects of security.

Once the TLS-protected data is received at the client and decrypted and authenticated by the TLS layer of the client system, the unencrypted data is available to the applications on the client platform.

These guidelines do not mitigate the threats against the misuse or exposure of the client credentials that reside on the client machine. These credentials could contain the private key used for client authentication or other credentials (e.g., a one-time password (OTP) or user ID and password) for authenticating to a server-side application.

For these reasons, the use of TLS does not obviate the need for the client to use appropriate security measures, as described in applicable Federal Information Processing Standards and NIST Special Publications, to protect computer systems and applications. Users shall operate client systems in accordance with agency and administrator instructions.

Selected acronyms and abbreviations used in this paper are defined below.

3DES — IETF mnemonic for Triple Data Encryption Algorithm

AEAD — Authenticated Encryption with Associated Data

AES — Advanced Encryption Standard

CA — Certification Authority

CBC — Cipher Block Chaining

CCM — Counter with CBC-MAC

CRL — Certificate Revocation List

DES — Data Encryption Standard

DH — Diffie-Hellman key exchange

DHE — Ephemeral Diffie-Hellman key exchange

DNS — Domain Name System

DNSSEC — DNS Security Extensions

DSA — Digital Signature Algorithm

DSS — Digital Signature Standard (implies DSA)

EC — Elliptic Curve

ECDHE — Ephemeral Elliptic Curve Diffie-Hellman

ECDSA — Elliptic Curve Digital Signature Algorithm

FIPS — Federal Information Processing Standard

GCM — Galois Counter Mode

HKDF — HMAC-based Extract-and-Expand Key Derivation Function

HMAC — Keyed-hash Message Authentication Code

IETF — Internet Engineering Task Force

KDF — Key Derivation Function

MAC — Message Authentication Code

OCSP — Online Certificate Status Protocol

OID — Object Identifier

PIV — Personal Identity Verification

PKCS — Public-Key Cryptography Standards

PKI — Public Key Infrastructure

PRF — Pseudo-random Function

PSK — Pre-Shared Key

RFC — Request for Comments

SHA — Secure Hash Algorithm

SSL — Secure Sockets Layer

TDEA — Triple Data Encryption Algorithm

TLS — Transport Layer Security

URL — Uniform Resource Locator

TLS cipher suite names consist of a set of mnemonics separated by underscores (i.e., “_”). The naming convention in TLS 1.3 differs from the convention shared in TLS 1.0, 1.1, and 1.2. Section B.1 provides guidance for interpreting the names of cipher suites that are recommended in these guidelines for TLS versions 1.0, 1.1, and 1.2. Section B.2 provides guidance for interpreting the names of cipher suites for TLS 1.3. In all TLS cipher suites, the first mnemonic is the protocol name (i.e., “TLS”).

B.1 Interpreting Cipher Suites Names in TLS 1.0, 1.1, and 1.2

As shown in Section 3.3.1, these cipher suites have the following form:

TLS_KeyExchangeAlg_WITH_EncryptionAlg_MessageAuthenticationAlg

KeyExchangeAlg consists of one or two mnemonics.

EncryptionAlg indicates the symmetric encryption algorithm and associated mode of operations.

MessageAuthenticationAlg is generally the hashing algorithm to be used for HMAC, if applicable.³⁶ In cases where HMAC is not applicable (e.g., AES-GCM) or the cipher suite was defined after the release of the TLS 1.2 RFC, this mnemonic represents the hashing algorithm used with the PRF.

The following examples illustrate how to interpret the cipher suite names:

As shown in Section 3.3.1, these cipher suites have the following form:

AEAD indicates the AEAD algorithm that is used for confidentiality, integrity, and message authentication. The NIST-approved TLS 1.3 AEAD algorithms comprise a NIST-recommended block cipher and NIST-recommended AEAD mode.

HASH indicates the hashing algorithm that is used with the HKDF during key derivation.

The following examples illustrate how to interpret TLS 1.3 cipher suite names:

The negotiation of the key exchange method is handled elsewhere in the TLS handshake.

Pre-shared keys (PSK) are symmetric keys that are already in place prior to the initiation of a TLS session (e.g., as the result of a manual distribution). The use of PSKs in TLS versions prior to TLS 1.3 is described in RFC 4279 [30], RFC 5487 [3], and RFC 5489 [4]. Pre-shared keys are used for session resumption in TLS 1.3. In general, pre-shared keys should not be used in TLS versions prior to TLS 1.3 or for initial session establishment in TLS 1.3. However, the use of pre-shared keys may be appropriate for some closed environments that have adequate key management support. For example, they might be appropriate for constrained environments with limited processing, memory, or power. If PSKs are appropriate and supported, then the following additional guidelines shall be followed.

Recommended pre-shared key (PSK) cipher suites for TLS 1.2 are listed below. Cipher suites for TLS 1.3 (see Section 3.3.1.2) can all be used with pre-shared keys. Pre-shared keys shall be distributed in a secure manner, such as a secure manual distribution or using a key-establishment certificate. These cipher suites employ a pre-shared key for entity authentication (for both the server and the client) and may also use ephemeral Diffie-Hellman (DHE) or ephemeral Elliptic Curve Diffie-Hellman (ECDHE) algorithms for key establishment. For example, when DHE is used, the result of the Diffie-Hellman computation is combined with the pre-shared key and other input to determine the premaster secret.

The pre-shared key shall have a minimum security strength of 112 bits. Because these cipher suites require pre-shared keys, these suites are not generally applicable to common secure website applications and are not expected to be widely supported in TLS clients or TLS servers. NIST suggests that pre-shared key cipher suites be considered for infrastructure applications, particularly if frequent authentication of the network entities is required.

Pre-shared key cipher suites may only be used in networks where both the client and server belong to the same organization. Cipher suites using pre-shared keys shall not be used with TLS 1.0 or 1.1 and shall not be used with TLS 1.2 when a government client or server communicates with non-government systems.

TLS 1.2 servers and clients using pre-shared keys may support the following cipher suites:

RSA key transport is a key exchange mechanism where the premaster secret is chosen by the client, encrypted with the server’s public key, and sent to the server. It is available in TLS versions 1.0 through 1.2, but it is not supported by TLS 1.3. While it is a convenient method for key exchange when the server’s certificate contains an RSA public key, this method has several drawbacks:

For these reasons, this guideline does not recommend cipher suites that use RSA key transport for key exchange (see Section 3.3.1).

Perfect forward secrecy (see Footnote 20) is often a security goal, as it prevents the compromise of long-term keys from enabling the decryption of sessions. The only way to achieve this property in TLS is to use a key exchange mechanism that relies on ephemeral parameters (i.e., cipher suites that contain DHE or ECDHE) as specified in RFC 5246 [25].

RSA key-transport using PKCS #1 v1.5 is vulnerable to Bleichenbacher oracle attacks. RFC 5246 contains steps to mitigate the attacks by processing incorrectly formatted messages in a manner indistinguishable from the processing of properly-formatted messages (see [25], Section 7.4.7.1). The mitigation techniques are not always effective in practice (for examples, see [14]).

D.1 Transition Period

While these guidelines do not recommend cipher suites using RSA key transport, there may be circumstances in practice where RSA key transport is needed. For example, if an agency uses a network appliance for regulatory or enterprise security purposes that only functions with these cipher suites, then these cipher suites may need to be enabled. It is recommended that agencies transition to a new method to meet their needs as soon as it is practical.

If RSA key transport is needed while a new traffic inspection strategy is being developed, only RSA key transport cipher suites from the following list may be used. See Section 3.3.1.1 for general information on preference order.

See transition guidance in SP 800-131A [10] for information on deprecation timelines.

This section identifies emerging concepts and capabilities that are applicable to TLS. As these concepts mature and commercial products are available to support them, these guidelines will be revised to provide specific recommendations.

E.1 U.S. Federal Public Trust PKI

The Identity, Credential, and Access Management (ICAM) Subcommittee of the Federal CIO Council’s Information Security and Identity Management Committee is developing a new public trust root and issuing CA infrastructure to issue TLS server certificates for federal web services on the public Internet. The intent is for this new root to be included in all of the commonly used trust stores so that federal agencies can obtain their TLS server certificates from this PKI rather than from commercial CAs. The certificate policy for this PKI is being developed at https://devicepki.idmanagement.gov.

Once this PKI is operational and is included in the commonly used trust stores, federal agencies should consider obtaining their TLS server certificates from this PKI.

E.2 DNS-based Authentication of Named Entities (DANE)

DANE leverages DNS security extensions (DNSSEC) to provide mechanisms for securely obtaining information about TLS server certificates from the DNS. RFC 6698 [34] specifies a resource record that may be made available in DNS that includes a certificate (or the public key of a certificate) along with an indicator of how the certificate is to be used. There are four options:

In each case, the client verifies the digital signatures on the DNS records in accordance with the DNSSEC as described in RFC 4033 [2].

E.3 Encrypted Server Name Indication

More information is encrypted in the TLS 1.3 handshake than in earlier versions of TLS; however, the client still sends the server name indication (SNI) extension (see Section 3.4.1.2) to the server in plain text. This means that an eavesdropper can determine the domain name of the server to which a client is connecting even if the eavesdropper was unable to listen in on the client’s DNS lookup and even if the server is hosting multiple domain names at the same IP address.

The TLS working group is working on the development of a mechanism for SNI encryption, which would allow the client to send the SNI to the server in encrypted form so that this information would not be accessible to eavesdroppers [35, 58]. Enabling support for this mechanism in TLS clients and servers would provide an additional level of privacy to TLS clients.

Enabling TLS 1.0 or 1.1 when they are not needed may leave systems and users vulnerable to attacks (such as the BEAST attack and the Klima attack [65]). However, disabling older versions of TLS when there is a need may deny access to users who are unable to install or upgrade to a client that is capable of TLS 1.3 or 1.2.

The system administrator must consider the benefits and risks of using TLS 1.0 or 1.1, in the context of applications supported by the server, and decide whether the benefits of using TLS 1.0 or 1.1 outweigh the risks. This decision should be driven by the service(s) running on the server and the versions supported by clients accessing the server. Services that do not access high-value information (such as personally identifiable information or financial data) may benefit from using TLS 1.0 by increasing accessibility with little increased risk. On the other hand, services that do access high-value data may increase the likelihood of a breach for relatively little gain in terms of accessibility. The decision to support TLS 1.0 or 1.1 must be technically assessed on a case-by-case basis. This is to ensure that supporting older TLS versions is absolutely necessary and that associated risks and business implications are understood and accepted.

These guidelines do not give specific recommendations on steps that can be taken to make this determination. There are tools available (such as the Data Analytics Program [69]) that can provide information to system administrators that can be used to assess the impact of supporting or not supporting TLS versions prior to TLS 1.2. For example, DAP data on visitor OS and browser versions can help administrators determine what percentage of visitors to agency websites cannot negotiate recommended TLS versions by default.

Many products that implement TLS 1.1 also implement TLS 1.2. Because of this, it may be unnecessary for servers to support TLS 1.1. Administrators can determine whether TLS 1.1 is needed by assessing whether it must support connections with clients where TLS 1.1 is the highest version available.

[1] AlFardan NJ, Paterson KG (2013) Lucky Thirteen: Breaking the TLS and DTLS Record Protocols. Available at http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

[2] Arends R, Austein R, Larson M, Massey D, Rose S (2005) DNS Security Introduction and Requirements. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 4033. https://doi.org/10.17487/RFC4033

[3] Badra M (2009) Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 5487. https://doi.org/10.17487/RFC5487

[4] Badra M, Hajjeh I (2009) ECDHE_PSK Cipher Suites for Transport Layer Security (TLS). (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 5489. https://doi.org/10.17487/RFC5489

[5] Barker EB (2016) Recommendation for Key Management Part 1: General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-57 Part 1, Rev. 4. https://doi.org/10.6028/NIST.SP.800-57pt1r4

[6] Barker EB, Chen L, Roginsky A, Vassilev A, Davis R (2018) Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56A, Rev. 3. https://doi.org/10.6028/NIST.SP.800-56Ar3

[7] Barker EB, Chen L, Roginsky A, Vassilev A, Davis R, Simon S (2019) Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-56B, Rev. 2. https://doi.org/10.6028/NIST.SP.800-56Br2

[8] Barker EB, Kelsey JM (2015) Recommendation for Random Number Generation Using Deterministic Random Bit Generators. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-90A, Rev. 1. https://doi.org/10.6028/NIST.SP.800-90Ar1

[9] Barker EB, Mouha N (2017) Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-67, Rev. 2. https://doi.org/10.6028/NIST.SP.800-67r2

[10] Barker EB, Roginsky A (2019) Transitioning the Use of Cryptographic Algorithms and Key Lengths. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-131A, Rev. 2. https://doi.org/10.6028/NIST.SP.800-131Ar2

[11] Be'ery T, Shulman A (2013) A Perfect CRIME? Only TIME Will Tell. Blackhat Europe 2013 (Amsterdam, The Netherlands). Available at https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf

[12] Bhargavan K, Delignat-Lavaud A, Fournet C, Pironti A, Strub PY (2014) Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS. 2014 IEEE Symposium on Security and Privacy (IEEE, San Jose, CA), pp 98-113. https://doi.org/10.1109/SP.2014.14

[13] Bhargavan K, Delignat-Lavaud A, Pironti A, Langley A, Ray M (2015) Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 7627. https://doi.org/10.17487/RFC7627

[14] Böck H, Somorovsky J, Young C (2017) Return Of Bleichenbacher's Oracle Threat (ROBOT). Cryptology ePrint Archive, Report 2017/1189. https://eprint.iacr.org/2017/1189

[15] Bradner S (1997) Key words for use in RFCs to Indicate Requirement Levels. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 2119. https://doi.org/10.17487/RFC2119

[16] CA/Browser Forum (2019) Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates. Available at https://cabforum.org/baseline-requirements-documents/

[17] CA/Browser Forum (2019) Guidelines For The Issuance And Management Of Extended Validation Certificates. Available at https://cabforum.org/extended-validation

[18] Chernick CM, Edington C, III, Fanto MJ, Rosenthal R (2005) Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-52. https://doi.org/10.6028/NIST.SP.800-52

[19] Cooper D, Santesson S, Farrell S, Boeyen S, Housley R, Polk W (2008) Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 5280. https://doi.org/10.17487/RFC5280

[20] Dang QH (2012) Recommendation for Applications Using Approved Hash Algorithms. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-107, Rev. 1. https://doi.org/10.6028/NIST.SP.800-107r1

[21] Dang QH (2011) Recommendation for Existing Application-Specific Key Derivation Functions. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-135, Rev. 1. https://doi.org/10.6028/NIST.SP.800-135r1

[22] Dang QH, Barker EB (2015) Recommendation for Key Management, Part 3:

[22] Dang QH, Barker EB (2015) Recommendation for Key Management, Part 3: Application-Specific Key Management Guidance. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-57 Part 3, Rev. 1. https://doi.org/10.6028/NIST.SP.800-57pt3r1

[23] Dierks T, Allen C (1999) The TLS Protocol Version 1.0. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 2246.

https://doi.org/10.17487/RFC2246

[24] Dierks T, Rescorla E (2006) The Transport Layer Security (TLS) Protocol Version 1.1. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 4346. https://doi.org/10.17487/RFC4346

[25] Dierks T, Rescorla E (2008) The Transport Layer Security (TLS) Protocol Version 1.2. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 5246. https://doi.org/10.17487/RFC5246

[26] Dworkin MJ (2007) Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-38D.

https://doi.org/10.6028/NIST.SP.800-38D

[27] Dworkin MJ (2001) Recommendation for Block Cipher Modes of Operation: Methods and Techniques. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-38A. https://doi.org/10.6028/NIST.SP.800-38A

[28] Dworkin MJ (2004) Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-38C, Includes updates as of July 20, 2007. https://doi.org/10.6028/NIST.SP.800-38C

[29] Eastlake D, III, (2011) Transport Layer Security (TLS) Extensions: Extension Definitions. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6066. https://doi.org/10.17487/RFC6066

[30] Eronen P, Tschofenig H (2005) Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). (Internet Engineering Task Force (IETF), Network Working Group), IETF Request for Comments (RFC) 4279. https://doi.org/10.17487/RFC4279

[31] Federal Public Key Infrastructure Policy Authority (2019) X.509 Certificate Policy For The U.S. Federal PKI Common Policy Framework. https://www.idmanagement.gov/topics/fpki/#certificate-policies

[32] Freier A, Karlton P, Kocher P (2011) The Secure Sockets Layer (SSL) Protocol Version 3.0. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6101.

https://doi.org/10.17487/RFC6101

[33] Gutmann P (2014) Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 7366. https://doi.org/10.17487/RFC7366

[34] Hoffman P, Schlyter J (2012) The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. (Internet Engineering Task

(DANE) Transport Layer Security (TLS) Protocol: TLSA. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6698. https://doi.org/10.17487/RFC6698

[35] Huitema C, Rescorla E (2018) Issues and Requirements for SNI Encryption in TLS. (Internet Engineering Task Force (IETF) Transport Layer Security Working Group), Internet-Draft draft-ietf-tls-sni-encryption-04. https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

[36] Joint Task Force Transformation Initiative (2013) Security and Privacy Controls for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 4, Includes updates as of January 22, 2015. https://doi.org/10.6028/NIST.SP.800-53r4

[37] Krawczyk H, Eronen P (2010) HMAC-based Extract-and-Expand Key Derivation Function (HKDF). (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 5869. https://doi.org/10.17487/RFC5869

[38] Langley A, (2014) The POODLE bites again. Available at https://www.imperialviolet.org/2014/12/08/poodleagain.html

[39] Langley A, Modadugu N, Moeller B (2016) Transport Layer Security (TLS) False Start. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 7918. https://doi.org/10.17487/RFC7918

[40] Laurie B, Langley A, Kasper E (2013) Certificate Transparency. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6962. https://doi.org/10.17487/RFC6962

[41] McGrew D, Bailey D (2012) AES-CCM Cipher Suites for Transport Layer Security (TLS). (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6655. https://doi.org/10.17487/RFC6655

[42] Moeller B, Langley A (2015) TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 7507. https://doi.org/10.17487/RFC7507

[43] Möller B, Duong T, Kotowicz K (2014) This POODLE Bites: Exploiting The SSL 3.0 Fallback. Available at https://www.openssl.org/~bodo/ssl-poodle.pdf

[44] National Institute of Standards and Technology (2001) Advanced Encryption Standard (AES). (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 197. https://doi.org/10.6028/NIST.FIPS.197

[45] National Institute of Standards and Technology (2013) Digital Signature Standard (DSS). (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 186-4. https://doi.org/10.6028/NIST.FIPS.186-4

[46] National Institute of Standards and Technology (2008) The Keyed-Hash Message Authentication Code (HMAC). (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 198-1.

https://doi.org/10.6028/NIST.FIPS.198-1

[47] National Institute of Standards and Technology (2013) Personal Identity Verification (PIV) of Federal Employees and Contractors. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 201-2.

https://doi.org/10.6028/NIST.FIPS.201-2

[48] National Institute of Standards and Technology (2019) Random Bit Generation. Available at https://csrc.nist.gov/Projects/Random-Bit-Generation

[49] National Institute of Standards and Technology (2015) Secure Hash Standard (SHS). (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 180-4. https://doi.org/10.6028/NIST.FIPS.180-4

[50] National Institute of Standards and Technology (2001) Security Requirements for Cryptographic Modules. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 140-2, Change Notice 2 December 03, 2002. https://doi.org/10.6028/NIST.FIPS.140-2

[51] National Institute of Standards and Technology (2019) Security Requirements for Cryptographic Modules. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 140-3. https://doi.org/10.6028/NIST.FIPS.140-3

[52] Nir Y, Josefsson S, Pegourie-Gonnard M (2018) Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 8422.

https://doi.org/10.17487/RFC8422

[53] Paterson KG, Ristenpart T, Shrimpton T (2011) Tag size does matter: attacks and proofs for the TLS record protocol. Advances in Cryptology – ASIACRYPT 2011, Lecture Notes in Computer Science, eds Lee DH, Wang X (Springer, Berlin), Vol. 7073, pp 372-389.

https://doi.org/10.1007/978-3-642-25385-0_20

[54] Pettersen Y (2013) The Transport Layer Security (TLS) Multiple Certificate Status Request Extension. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6961. https://doi.org/10.17487/RFC6961

[55] Polk T, McKay KA, Chokhani S (2014) Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-52, Rev. 1.

https://doi.org/10.6028/NIST.SP.800-52r1

[56] Rescorla E (2008) TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM). (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 5289. https://doi.org/10.17487/RFC5289

[57] Rescorla E (2018) The Transport Layer Security (TLS) Protocol Version 1.3. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 8446. https://doi.org/10.17487/RFC8446

[58] Rescorla E, Oku K, Sullivan N, Wood C (2019) Encrypted Server Name Indication for TLS 1.3. (Internet Engineering Task Force (IETF) Transport Layer Security Working Group), Internet-Draft draft-ietf-tls-esni-04. https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

[59] Rescorla E, Ray M, Dispensa S, Oskov N (2010) Transport Layer Security (TLS) Renegotiation Indication Extension. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 5746. https://doi.org/10.17487/RFC5746

[60] Rizzo J, Duong T (2012) The CRIME Attack. EKOparty Security Conference 2012 (Buenos Aires, Argentina). Available at https://www.ekoparty.org/archivo/2012/eko8-CRIME.pdf

[61] Salowey J, Choudhury A, McGrew D (2008) AES Galois Counter Mode (GCM) Cipher Suites for TLS. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 5288. https://doi.org/10.17487/RFC5288

[62] Salowey J, Zhou H, Eronen P, Tschofenig H (2008) Transport Layer Security (TLS) Session Resumption without Server-Side State. (Internet Engineering Task Force (IETF) Network Working Group), IETF Request for Comments (RFC) 5077. https://doi.org/10.17487/RFC5077

[63] Santesson S, Myers M, Ankney R, Malpani A, Galperin S, Adams C (2013) X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6960. https://doi.org/10.17487/RFC6960

[64] Seggelmann R, Tuexen M, Williams M (2012) Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6520. https://doi.org/10.17487/RFC6520

[65] Sheffer Y, Holz R, Saint-Andre P (2015) Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 7457. https://doi.org/10.17487/RFC7457

[66] Sönmez Turan M, Barker EB, Kelsey JM, McKay KA, Baish ML, Boyle M (2018) Recommendation for the Entropy Sources Used for Random Bit Generation. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-90B. https://doi.org/10.6028/NIST.SP.800-90B

[67] Springall D, Durumeric Z, Halderman JA (2016) Measuring the Security Harm of TLS Crypto Shortcuts. IMC'16 Proceedings of the 2016 Internet Measurement Conference (ACM, Santa Monica, California), pp 33-47. https://doi.org/10.1145/2987443.2987480

[68] Federal Bridge Certification Authority (2019) X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA). Available at https://www.idmanagement.gov/topics/fpki/#certificate-policies

[69] U.S. General Services Administration (2019) DAP: Digital Analytics Program. Available at https://digital.gov/dap

[70] US-CERT/NIST (2014) CVE-2014-0160 Detail. National Vulnerability Database.

Available at https://nvd.nist.gov/vuln/detail/CVE-2014-0160

[71] Wouters P, Tschofenig H, Gilmore J, Weiler S, Kivinen T (2014) Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 7250.

https://doi.org/10.17487/RFC7250

[72] Yee P (2013) Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6818. https://doi.org/10.17487/RFC6818

H.1 Original

The original version of SP 800-52 was published in June 2005 [18]. At the time, only TLS 1.0 was final (TLS 1.1 was still under development). TLS 1.1 became a standard in April 2006, and TLS 1.2 became a standard in August 2008. SP 800-52 became outdated, and guidance on keys and cipher suites was incorporated into SP 800-57 Part 3 [22]. In March 2013, SP 800-52 was withdrawn.

H.2 Revision 1

The first revision of SP 800-52 was published in April 2014 [55]. The revision was a new document that bore little resemblance to the original. At the time, TLS 1.2 was still not prevalent, and the Federal PKI consisted mainly of RSA certificates. Recommendations were made with this in mind so that federal agencies could follow the guidelines with either existing technology or technology that was under development. Agencies were advised to develop a plan to migrate to TLS 1.2.

After revision 1 was posted, the guidance on keys and cipher suites was removed from SP 800-57 Part 3.

H.3 Revision 2

Since revision 1, support for TLS 1.2 and cipher suites using ephemeral key exchanges has increased, and new attacks have come to light. Revision 2 (this document) requires that TLS 1.2 be supported and contains several changes to certificate and cipher suite recommendations.

Revision 2 includes recommendations for TLS 1.3. TLS 1.3 offers many improvements over previous versions of TLS, so revision 2 advises agencies to develop a plan to migrate to TLS 1.3.

Revision 2 also has increased discussion on TLS attacks and guidance on mitigation.

Certificate requirements have also changed in this revision. In particular, status information for TLS server certificates is required to be made available via the Online Certificate Status Protocol. This revision of the TLS guidelines relaxes requirements on which signature algorithms can sign which key types in certificates.