NIST Special Publication 800-52
Revision 2

Guidelines for the Selection,
Configuration, and Use of Transport
Layer Security (TLS) Implementations
Kerry A. McKayDavid A. CooperThis publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-52r2

C O M P U T E R

S E C U R I T Y

NIST Special Publication 800-52
Revision 2

Guidelines for the Selection,
Configuration, and Use of Transport
Layer Security (TLS) Implementations
Kerry A. McKayDavid 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

Authority
This publication has been developed by NIST in accordance with its statutory responsibilities under theFederal 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 andbinding on federal agencies by the Secretary of Commerce under statutory authority. Nor should theseguidelines 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 nongovernmentalorganizations 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: NSPUE2This 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.
There may be references in this publication to other publications currently under development by NIST in accordancewith 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 eachpublication 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 athttps://csrc.nist.gov/publications.

Comments on this publication may be submitted to:
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).

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

Reports on Computer Systems Technology

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

The Information Technology Laboratory (ITL) at the National Institute of Standards andTechnology (NIST) promotes the U.S. economy and public welfare by providing technicalleadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test
methods, reference data, proof of concept implementations, and technical analyses to advancethe development and productive use of information technology. ITL’s responsibilities include thedevelopment of management, administrative, technical, and physical standards and guidelines forthe cost-effective security and privacy of other than national security-related information infederal 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.
Abstract
Transport Layer Security (TLS) provides mechanisms to protect data during electronic
dissemination across the Internet. This Special Publication provides guidance to the selection andconfiguration 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.
Keywords
information security; network security; SSL; TLS; Transport Layer Security
Acknowledgements
The authors, Kerry McKay and David Cooper of the National Institute of Standards andTechnology (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 andCharles Edington III and Rob Rosenthal of Booz Allen Hamilton who wrote the initial publishedversion of this document.
Audience
This document assumes that the reader of these guidelines is familiar with TLS protocols andpublic-key infrastructure concepts, including, for example, X.509 certificates.
The guidelines in this document are specifically targeted towards U.S. federal departments andagencies. 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.
ii

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

Executive Summary
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 canbecome 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.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-52r2

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 andalgorithms. In particular, it requires that TLS 1.2 be configured with cipher suites using NISTapproved schemes and algorithms as the minimum appropriate secure transport protocol andrequires 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:•

More consistent use of authentication, confidentiality, and integrity mechanisms for theprotection of information transported across the Internet;•

Consistent use of the recommended cipher suites that encompass NIST-approved
algorithms and open standards;•

Protection against known and anticipated attacks on the TLS protocol; and1 While SSL 3.0 is the most secure of the SSL protocol versions, it is not approved for use in the protection of Federal

information because it relies in part on the use of cryptographic algorithms that are not NIST-approved. TLS 1.2 is approved
for the protection of Federal information when properly configured. TLS versions 1.1 and 1.0 are approved only when they are
required for interoperability with non-government systems and are configured according to these guidelines.

iii

NIST SP 800-52 REV. 2•

GUIDELINES FOR TLS IMPLEMENTATIONS

Informed decisions by system administrators and managers in the integration of TLS
implementations.

While these guidelines are primarily designed for federal users and system administrators toadequately 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.

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

iv

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

Table of Contents
Executive Summary ..................................................................................................... iii
1

Introduction ............................................................................................................ 1
1.1 History of TLS ................................................................................................. 1
1.2 Scope.............................................................................................................. 2
1.2.1 Alternative Configurations .................................................................... 3
1.3 Document Conventions................................................................................... 3

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

2

TLS Overview ......................................................................................................... 4
2.1 TLS Subprotocols ........................................................................................... 4
2.2 Shared Secret Negotiation .............................................................................. 5
2.3 Confidentiality ................................................................................................. 5
2.4 Integrity ........................................................................................................... 6
2.5 Authentication ................................................................................................. 6
2.6 Anti-Replay ..................................................................................................... 7
2.7 Key Management ............................................................................................ 7

3

Minimum Requirements for TLS Servers ............................................................. 8
3.1 Protocol Version Support ................................................................................ 8
3.2 Server Keys and Certificates .......................................................................... 9
3.2.1 Server Certificate Profile..................................................................... 10
3.2.2 Obtaining Revocation Status Information for the Client Certificate ..... 12
3.2.3 Server Public-Key Certificate Assurance ............................................ 13
3.3 Cryptographic Support .................................................................................. 14
3.3.1 Cipher Suites ...................................................................................... 14
3.3.2 Implementation Considerations .......................................................... 20
3.3.3 Validated Cryptography ...................................................................... 20
3.4 TLS Extension Support ................................................................................. 21
3.4.1 Mandatory TLS Extensions ................................................................ 22
3.4.2 Conditional TLS Extensions ............................................................... 23
3.4.3 Discouraged TLS Extensions ............................................................. 28
3.5 Client Authentication ..................................................................................... 29
3.5.1 Path Validation ................................................................................... 29
3.5.2 Trust Anchor Store ............................................................................. 30v

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

3.5.3 Checking the Client Key Size ............................................................. 30
3.5.4 Server Hints List ................................................................................. 31
3.6 Session Resumption and Early Data ............................................................ 31
3.7 Compression Methods .................................................................................. 32
3.8 Operational Considerations .......................................................................... 32
4

Minimum Requirements for TLS Clients ............................................................ 33
4.1 Protocol Version Support .............................................................................. 33
4.2 Client Keys and Certificates .......................................................................... 33

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

4.2.1 Client Certificate Profile ...................................................................... 33
4.2.2 Obtaining Revocation Status Information for the Server Certificate ... 35
4.2.3 Client Public-Key Certificate Assurance ............................................. 36
4.3 Cryptographic Support .................................................................................. 36
4.3.1 Cipher Suites ...................................................................................... 36
4.3.2 Validated Cryptography ...................................................................... 37
4.4 TLS Extension Support ................................................................................. 37
4.4.1 Mandatory TLS Extensions ................................................................ 37
4.4.2 Conditional TLS Extensions ............................................................... 38
4.4.3 Discouraged TLS Extensions ............................................................. 42
4.5 Server Authentication.................................................................................... 42
4.5.1 Path Validation ................................................................................... 42
4.5.2 Trust Anchor Store ............................................................................. 43
4.5.3 Checking the Server Key Size ............................................................ 43
4.5.4 User Interface ..................................................................................... 43
4.6 Session Resumption and Early Data ............................................................ 44
4.7 Compression Methods .................................................................................. 44
4.8 Operational Considerations .......................................................................... 44
List of Appendices
Appendix A— Acronyms ............................................................................................ 45
Appendix B— Interpreting Cipher Suite Names ....................................................... 47
B.1 Interpreting Cipher Suites Names in TLS 1.0, 1.1, and 1.2 ........................... 47
B.2 Interpreting Cipher Suites Names in TLS 1.3 ................................................ 48
Appendix C— Pre-shared Keys ................................................................................. 49vi

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSAppendix D— RSA Key Transport ............................................................................. 51
D.1 Transition Period ........................................................................................... 51
Appendix E— Future Capabilities .............................................................................. 53
E.1 U.S. Federal Public Trust PKI ....................................................................... 53
E.2 DNS-based Authentication of Named Entities (DANE) ................................. 53
E.3 Encrypted Server Name Indication ............................................................... 54
Appendix F— Determining the Need for TLS 1.0 and 1.1 ........................................ 55
Appendix G— References .......................................................................................... 56
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-52r2

Appendix H— Revision History ................................................................................. 63
H.1 Original ......................................................................................................... 63
H.2 Revision 1 ..................................................................................................... 63
H.3 Revision 2 ..................................................................................................... 63vii

NIST SP 800-52 REV. 2

1

GUIDELINES FOR TLS IMPLEMENTATIONSIntroduction

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), andsocial transactions (e.g., email or social networking). Any network service that handles sensitiveor 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-13 2 requires that all publicly accessible federal websites and web services
only provide service through a secure connection. 3 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 theTransmission Control Protocol (TCP). Application protocols, such as the Hypertext Transfer
Protocol (HTTP) and the Internet Message Access Protocol (IMAP), can run above TLS. TLS isapplication-independent and used to provide security to any two communicating applications thattransmit data over a network via an application protocol.
1.1

History of TLS

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 nevercommanded 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 toensure 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 andwas 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 thatTLS 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 4 to prevent a certain class of attacks on the Cipher

2 https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2015/m-15-13.pdf
3 See https://https.cio.gov/ for more details on this initiative.
4 The initialization vector (IV) must be sent; it cannot be derived from a state known by both parties, such as the previous

message.

1

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSBlock Chaining (CBC) mode of operation used by TLS. The handling of padding errors wasaltered 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 todefend 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 inthe area of hash functions, with the ability to use or specify the SHA-2 family of algorithms forhash, MAC, and Pseudorandom Function (PRF) computations. TLS 1.2 also adds authenticatedencryption 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 DiffieHellman (DH) key exchanges, the CBC mode of operation, or SHA-1. Many extensions definedfor use with TLS 1.2 and previous versions cannot be used with TLS 1.3.
1.2

Scope

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 usuallyderived from a risk assessment of the threats or attacks that an adversary is likely to mountagainst a system. The adversary is likely to take advantage of implementation vulnerabilities
found in many system components, including computer operating systems, application softwaresystems, and the computer networks that interconnect them. Thus, in order to secure a systemagainst a myriad of threats, security must be judiciously placed in the various systems andnetwork 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 interoperatewith 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 wheresecurity is needed but broad interoperability is not required, and the cost of implementing unusedfeatures 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 toremotely 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
2

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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 theseguidelines. NIST may issue separate guidelines for DTLS at a later date.
1.2.1

Alternative Configurations

TLS may be used to secure the communications of a wide variety of applications in a diverse setof 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, theneeds of an agency or application may differ from general needs. Deviations from theseguidelines are acceptable, provided that agencies and system administrators assess andaccept the risks associated with alternative configurations in terms of both security andinteroperability.
1.3

Document Conventions

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 othernormative documents [15]. In addition to the key words, the words “need,” “can,” and “may” areused 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.

3

NIST SP 800-52 REV. 2

2

GUIDELINES FOR TLS IMPLEMENTATIONSTLS Overview

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 toprocess 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 tothe 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.
2.1

TLS Subprotocols

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 tonegotiate 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 thecryptographic 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 theserver. 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 canbe configured so that one or more of the following security services are negotiated during thehandshake: 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 5 toauthenticate 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 andserver negotiate algorithms for authentication, confidentiality, and integrity, as well as derive

5 In these guidelines, the terms “certificate” and “public-key certificate” are used interchangeably.

4

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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].
2.2

Shared Secret Negotiation

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 andthe 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 pseudorandomfunction (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 mastersecret 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 theclient and the server to communicate.
The establishment of these secrets is secure against eavesdroppers. When the TLS protocol isused in accordance with these guidelines, the application data, as well as the secrets, are notvulnerable 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.
2.3

Confidentiality

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 theappropriate derived encryption key; the receiver uses the same (independently derived) key todecrypt the message. Both the client and server know these keys and decrypt the messages using
the same key that was used for encryption.

5

NIST SP 800-52 REV. 2

2.4

GUIDELINES FOR TLS IMPLEMENTATIONS

Integrity

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 senderof 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’swrite 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 hashalgorithm 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 mastersecret.
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 andconfidentiality. 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 themessage 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.
2.5

Authentication

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 forserver authentication is dependent on the negotiated security parameters and extensions. In manycases, authentication is performed explicitly by verifying digital signatures using public keys thatare present in certificates or implicitly by the use of the server public key by the client during theestablishment 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 isbased on the client’s public-key certificate. The exact nature of the cryptographic operation forclient authentication depends on the negotiated cipher suite’s key-exchange algorithm and thenegotiated 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.

6

NIST SP 800-52 REV. 2

2.6

GUIDELINES FOR TLS IMPLEMENTATIONS

Anti-Replay

TLS provides inherent protection against replay attacks, except when 0-RTT data (optionallysent in the first flight of handshake messages) is sent in TLS 1.3. 6 The integrity-protectedenvelope of the message contains a monotonically increasing sequence number. Once themessage integrity is verified, the sequence number of the current message is compared with thesequence 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 themessage.
2.7

Key Management

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 toall 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 theseguidelines.
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 canobtain a public-key certificate for a public key corresponding to his own private key in the nameof a client from a CA trusted by the server, the third party can masquerade as that client to theserver. Requirements and recommendations to mitigate these concerns are addressed later inthese guidelines.
Since the random numbers generated by the client and server contribute to the randomness of thesession keys, the client and server must be capable of generating random numbers with at least
112 bits of security 7 each. The various TLS session keys derived from these random values andother data are valid for the duration of the session. Because the session keys are only used toprotect 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 thestored key as a form of authentication.

6 While TLS 1.3 does not inherently provide replay protection with 0-RTT data, the TLS 1.3 specification does recommend

mechanisms to protect against replay attacks (see Section 8 of [57]).

7 See the SP 800-90 series for more information on random bit generators (https://csrc.nist.gov/projects/random-bit-generation).

7

NIST SP 800-52 REV. 2

3

GUIDELINES FOR TLS IMPLEMENTATIONSMinimum Requirements for TLS Servers

This section provides a minimum set of requirements that a server must implement in order tomeet 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 withadditional commercial products to meet the requirements. Configuration requirements indicatethat TLS server administrators are required to verify that particular features are enabled or
disabled, or in some cases, configured appropriately, if present.
3.1

Protocol Version Support

Servers that support government-only applications 8 shall be configured to use TLS 1.2 andshould 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 bymajor and minor number tuples (3, 3) and (3, 4), respectively, and may appear in that format
during configuration. 9Servers that support citizen or business-facing applications (i.e., the client may not be part of agovernment IT system) 10 shall be configured to negotiate TLS 1.2 and should be configured tonegotiate 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 bedisabled on servers that support TLS 1.3 if it has been determined that TLS 1.2 is not needed forinteroperability.
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
8 A government-only application is an application where the intended users are exclusively government employees or contractors

working on behalf of the government. This includes applications that are accessed on a government employee’s bring-yourown-device (BYOD) system.

9 Historically, TLS 1.0 was assigned major and minor tuple (3,1) to align it as SSL 3.1. TLS 1.1 is represented by the major andminor tuple (3,2).

10 For the purposes of this document, clients that reside on “bring your own device” (BYOD) systems or privately-owned systems

used to perform telework are considered to be part of the government IT system, as they access services that are notavailable to the public.

8

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

newer than TLS 1.0. Servers that incorrectly implement TLS version negotiation shall not be
used.
3.2

Server Keys and Certificates

The TLS server shall be configured with one or more public-key certificates and the associatedprivate keys. TLS server implementations should support the use of multiple server certificateswith 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) 11 signature certificate, aDiffie-Hellman (DH) certificate, and an Elliptic Curve Diffie-Hellman (ECDH) certificate. At aminimum, TLS servers conforming to this specification shall be configured with an RSA
signature certificate or an ECDSA signature certificate. The other certificate types and theirassociated 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 isconfigured with an ECDSA signature certificate, either curve P-256 or curve P-384 should be
used for the public key in the certificate. 12
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 theappropriate 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 theappropriate 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, suchas 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 whenassociating 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.

11 In the names for the TLS cipher suites, DSA is referred to as DSS (Digital Signature Standard) for historical reasons.

12

The recommended elliptic curves now listed in FIPS 186-4 [45] will be moved to SP 800-186. Until SP 800-186 is published,
the recommended elliptic curves should be taken from FIPS 186-4.

9

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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 forrevocation checking. Section 3.5.4 specifies requirements for the “hints list.”
3.2.1

Server Certificate Profile

The server certificate profile, described in this section, provides requirements andrecommendations for the format of the server certificate. To comply with these guidelines, theTLS 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, theserver 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: 13,14•

Certificates containing RSA, ECDSA, or DSA public keys should be signed with thosesame signature algorithms, respectively;•

Certificates containing Diffie-Hellman public keys should be signed with DSA; and•Certificates containing ECDH public keys should be signed with ECDSA.

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 theserver DNS name in the Subject Alternative Name field ensures that any name constraints on thecertification 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
Field

CriticalValue

Description

VersionN/A

2

Version 3

Serial Number

N/A

Unique positive integer

Must be unique

13 This recommendation is an artifact of requirements in TLS 1.0 and 1.1.
14 Algorithm-dependent guidelines exist for the generation of public and private key pairs. For guidance on the generation of DH

and ECDH key pairs, see SP 800-56A [6]. For guidance regarding the generation of RSA, DSA and ECDSA key pairs, see
[45].

10

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

Field

CriticalIssuer Signature Algorithm

N/A

Value

Description
Values by CA key type:sha256WithRSAEncryption {1 2 840
113549 1 1 11}, or stronger

CA with RSA key

id-RSASSA-PSS {1 2 840 113549 1 1 10}

CA with RSA key

ecdsa-with-SHA256 {1 2 840 10045 4 32}, or stronger

CA with elliptic curve key

id-dsa-with-sha256 {2 16 840 1 101 3 4 32}, or stronger

CA with DSA key

Issuer Distinguished Name
(DN)

N/A

Unique X.500 issuing CA DN

A single value should be encoded in each
Relative Distinguished Name (RDN). All
attributes that are of DirectoryString typeshould be encoded as a PrintableString.

Validity Period

N/A

3 years or lessDates through 2049 expressed in UTCTime

Subject Distinguished Name

N/A

Unique X.500 subject DN per agency
requirements

A single value should be encoded in each
RDN. All attributes that are of
DirectoryString type should be encoded asa PrintableString. If present, the CN
attribute should be of the form:

Subject Public Key
Information

N/A

CN={host IP address | host DNS name}
Values by certificate type:rsaEncryption {1 2 840 113549 1 1 1}

RSA signature certificate
2048-bit RSA key modulus or otherapproved lengths as defined in [45] and [5]Parameters: NULL

ecPublicKey {1 2 840 10045 2 1}

ECDSA signature certificate or ECDH
certificate
Parameters: namedCurve OID for named
curve specified in SP 800-186. 15 The curveshould be P-256 or P-384
SubjectPublic Key: Uncompressed EC
Point.

id-dsa {1 2 840 10040 4 1}

DSA signature certificate
Parameters: p, q, g (2048-bit large prime,i.e., p)dhpublicnumber {1 2 840 10046 2 1}

DH certificate
Parameters: p, g, q (2048-bit large prime,i.e., p)N/A

Same value as in Issuer Signature
Algorithm

Authority Key IdentifierNo

Octet String

Subject Key IdentifierNo

Octet String

Key Usage

Yes

Issuer’s Signature
Extensions

Same as subject key identifier in issuing
CA certificate
Prohibited: Issuer DN, Serial Number tuple
Same as in Public-Key CryptographyStandards (PKCS) 10 request or calculatedby the issuing CA
Values by certificate type:

digitalSignature

RSA signature certificate, ECDSA
signature certificate, or DSA signature
certificate

11

NIST SP 800-52 REV. 2
Field

GUIDELINES FOR TLS IMPLEMENTATIONS
Critical

Extended Key Usage

No

Value

Description

keyAgreement

ECDH certificate, DH certificate

id-kp-serverAuth {1 3 6 1 5 5 7 3 1}

Required

id-kp-clientAuth {1 3 6 1 5 5 7 3 2}

Optional
Prohibited: anyExtendedKeyUsage; allothers unless consistent with key usage
extension

Certificate Policies

No

Subject Alternative Name
(SAN)

No

DNS host name, or IP address if there is
no DNS name assigned. Other nameforms may be included, if appropriate.

Required. Multiple SANs are permitted,
e.g., for load balanced environments.

Authority Information AccessNo

id-ad-caIssuers

Required. Access method entry contains
HTTP URL for certificates issued to
issuing CA

id-ad-ocsp

Required. Access method entry contains
HTTP URL for the issuing CA OCSP
responder

See comments

Optional. HTTP value in distributionPoint
field pointing to a full and complete CRL.

CRL Distribution Points

No

Optional

Prohibited: reasons and cRLIssuer fields,
and nameRelativetoCRLIssuer CHOICE
Signed Certificate
Timestamps ListNo

See comments

Optional. This extension contains asequence of Signed Certificate
Timestamps, which provide evidence thatthe certificate has been submitted to
Certificate Transparency logs.

TLS featureNostatus_request(5)Optional. This extension (sometimes
referred to as the “must staple” extension)
may be present to indicate to clients thatthe server supports OCSP stapling and will
provide a stapled OCSP response when one
is requested.

3.2.2

Obtaining Revocation Status Information for the Client Certificate

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 thefollowing locations:
1. Certificate Revocation List (CRL) or OCSP [63] response in the server’s local store;
2. OCSP response from a locally-configured OCSP responder;
3. OCSP response from the OCSP responder location identified in the OCSP field in the
Authority Information Access extension in the client certificate; or

15 The recommended elliptic curves now listed in FIPS 186-4 [45] will be moved to SP 800-186. Until SP 800-186 is published,

the recommended elliptic curves should be taken from FIPS 186-4.

12

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

4. CRL from the CRL Distribution Points extension in the client certificate.
When the local store does not have the current or a cogent 16 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.
3.2.3

Server Public-Key Certificate Assurance

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 withthe 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 theregistration 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 theirtrust anchor to remain in browser trust stores [16]. Under another effort, the CA Browser Forumhas written guidelines for issuing Extended Validation Certificates [17].
Several concepts are under development that further mitigate the risks associated with thecompromise 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 thecertificate using the certificatePolicies extension, specified in [19] and updated in [72]. Whenused, one or more certificate policy object identifiers (OID) are asserted in this extension, witheach 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 theagency’s control, the agency may issue the certificate from its own CA if it can configure theclients to trust that CA. In other cases, the agency should obtain a certificate from a publiclytrusted CA (a CA that clients that will be connecting to the server have already been configured
to trust).

16 A CRL is considered “cogent” when the “CRL Scope” [19] is appropriate for the certificate in question.

13

NIST SP 800-52 REV. 2

3.3

GUIDELINES FOR TLS IMPLEMENTATIONSCryptographic Support

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) 17 and forproviding 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 tothe 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 haveadditional considerations specific to the implementation of the cryptographic algorithms, as wellas cryptographic module validation requirements. Acceptable cipher suites are listed in Section
3.3.1, grouped by certificate type and protocol version. Cipher suite implementationconsiderations are discussed in Section 3.3.2, and recommendations regarding cryptographic
module validation are described in Section 3.3.3.
3.3.1

Cipher Suites

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 AES128 (Advanced Encryption Standard with 128-bit key) in cipher block chaining mode, andmessage authentication performed using HMAC_SHA. 18 For further information on cipher suiteinterpretation, 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:
TLS_AEAD_HASHFor 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 tobe 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
17 In TLS 1.3, the key exchange algorithm is specified solely in extensions (see Sections 3.4.2.3 and 3.4.2.10).
18 SHA indicates the use of the SHA-1 hash algorithm.

14

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

preference order, and it may be different from the client’s. Therefore, there is no guarantee thatthe negotiation will settle on the strongest common suite. If no cipher suites are common to theclient and server, the connection is aborted.
The server shall be configured to only use cipher suites that are composed entirely of NISTapproved 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. 19
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 orenvironments may require the use of RSA key transport during a transition period. Acceptablecipher 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 shallnot be used.
Cipher suites using ephemeral DH and ephemeral ECDH (i.e., those with DHE or ECDHE in thesecond mnemonic) provide perfect forward secrecy. 20 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.
3.3.1.1 Cipher Suites for TLS 1.2 and Earlier Versions

The first revision of this guidance required support for a small set of cipher suites to promoteinteroperability 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 signatureproviding at least 112 bits of security.

19 The full list of IANA values for TLS parameters can be found at https://www.iana.org/assignments/tls-parameters/tls-

parameters.xhtml.

20 Perfect forward secrecy is the condition in which the compromise of a long-term private key after it has been used to establish

a session key does not cause the compromise of that session key.

15

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

By removing requirements that specific cipher suites be supported, system administrators havemore 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, thefollowing list gives general guidance on choosing the strongest options:
1. Prefer ephemeral keys over static keys (i.e., prefer DHE over DH, and prefer ECDHE
over ECDH). Ephemeral keys provide perfect forward secrecy.
2. Prefer GCM or CCM modes over CBC mode. The use of an authenticated encryption
mode prevents several attacks (see Section 3.3.2 for more information). Note that these
are not available in versions prior to TLS 1.2.
3. Prefer CCM over CCM_8. The latter contains a shorter authentication tag, which
provides a lower authentication strength.
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).
3.3.1.1.1 Cipher Suites for ECDSA Certificates

TLS version 1.2 includes authenticated encryption modes and support for the SHA-256 andSHA-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_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2B)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x2C)
TLS_ECDHE_ECDSA_WITH_AES_128_CCM (0xC0, 0xAC)
TLS_ECDHE_ECDSA_WITH_AES_256_CCM (0xC0, 0xAD)
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (0xC0, 0xAE)
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (0xC0, 0xAF)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xC0, 0x23)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xC0, 0x24)

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

16

NIST SP 800-52 REV. 2••

GUIDELINES FOR TLS IMPLEMENTATIONSTLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 21 (0xC0, 0x09)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xC0, 0x0A)

3.3.1.1.2 Cipher Suites for RSA Certificates

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

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2F)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x30)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x00, 0x9E)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x00, 0x9F)
TLS_DHE_RSA_WITH_AES_128_CCM (0xC0, 0x9E)
TLS_DHE_RSA_WITH_AES_256_CCM (0xC0, 0x9F)
TLS_DHE_RSA_WITH_AES_128_CCM_8 (0xC0, 0xA2)
TLS_DHE_RSA_WITH_AES_256_CCM_8 (0xC0, 0xA3)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xC0, 0x27)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xC0, 0x28)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x00, 0x67)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x00, 0x6B)

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

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC0, 0x13)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC0, 0x14)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x00, 0x33)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x00, 0x39)

3.3.1.1.3 Cipher Suites for DSA Certificates

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

TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00, 0xA2)
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00, 0xA3)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x00, 0x40)

21 In TLS versions 1.0 and 1.1, DHE and ECDHE cipher suites use SHA-1 for signature generation on the ephemeral parameters(including keys) in the ServerKeyExchange message. While the use of SHA-1 for digital signature generation is generally
disallowed by [10], exceptions can be granted by protocol-specific guidance. SHA-1 is allowed for generating digital
signatures on ephemeral parameters in TLS. Due to the random nature of the ephemeral keys, a third party is unlikely tocause effective collision. The server and client do not have anything to gain by causing a collision for the connection.
Because of the client random and server random values, the server, the client, or a third party cannot use a colliding set of
messages to masquerade as the client or server in future connections. Any modification to the parameters by a third party
during the handshake will ultimately result in a failed connection.

17

NIST SP 800-52 REV. 2•

GUIDELINES FOR TLS IMPLEMENTATIONSTLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x00, 0x6A)

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

TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x00, 0x32)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x00, 0x38)

3.3.1.1.4 Cipher Suites for DH Certificates

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 ofstatic keys is technically acceptable, the use of ephemeral key cipher suites is encouraged andpreferred 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 tosupport the following cipher suites:••••

TLS_DH_DSS_WITH_AES_128_GCM_SHA256 (0x00, 0xA4)
TLS_DH_DSS_WITH_AES_256_GCM_SHA384 (0x00, 0xA5)
TLS_DH_DSS_WITH_AES_128_CBC_SHA256 (0x00, 0x3E)
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 (0x00, 0x68)

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_DH_DSS_WITH_AES_128_CBC_SHA (0x00, 0x30)
TLS_DH_DSS_WITH_AES_256_CBC_SHA (0x00, 0x36)

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

TLS_DH_RSA_WITH_AES_128_GCM_SHA256 (0x00, 0xA0)
TLS_DH_RSA_WITH_AES_256_GCM_SHA384 (0x00, 0xA1)
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 (0x00, 0x3F)
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 (0x00, 0x69)

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:••

TLS_DH_RSA_WITH_AES_128_CBC_SHA (0x00, 0x31)
TLS_DH_RSA_WITH_AES_256_CBC_SHA (0x00, 0x37)

3.3.1.1.5 Cipher Suites for ECDH Certificates

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
18

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x2D)
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x2E)
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xC0, 0x25)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xC0, 0x26)

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_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xC0, 0x04)
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xC0, 0x05)

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

TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xC0, 0x31)
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xC0, 0x32)
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xC0, 0x29)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xC0, 0x2A)

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_ECDH_RSA_WITH_AES_128_CBC_SHA (0xC0, 0x0E)
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xC0, 0x0F)

3.3.1.2 Cipher Suites for TLS 1.3

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

TLS_AES_128_GCM_SHA256 (0x13, 0x01)
TLS_AES_256_GCM_SHA384 (0x13, 0x02)
TLS_AES_128_CCM_SHA256 (0x13, 0x04)
TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)

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-sharedkeys, as specified in Appendix C.

19

NIST SP 800-52 REV. 2

3.3.2

GUIDELINES FOR TLS IMPLEMENTATIONS

Implementation Considerations

System administrators need to fully understand the ramifications of selecting cipher suites andconfiguring applications to support only those cipher suites. The security guarantees of thecryptography are limited to the weakest cipher suite supported by the configuration. Whenconfiguring 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 whencommunications 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.
3.3.2.1 Algorithm Support

Many TLS servers and clients support cipher suites that are not composed of only NISTapproved algorithms. Therefore, it is important that the server is configured to only use NISTrecommended cipher suites. This is particularly important for server implementations that do notallow the server administrator to specify preference order. In such servers, the only way toensure that a server uses NIST-approved algorithms is to disable cipher suites that use otheralgorithms.
If the server implementation does allow the server administrator to specify a preference, thesystem administrator is encouraged to use the preference recommendations listed in Section
3.3.1.1.
3.3.3

Validated Cryptography

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 sothat if one hash function is broken, security is not compromised. While MD5 is not a NISTapproved algorithm, the PRF is specified as acceptable in SP 800-135 [21]. In TLS 1.2, the20

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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 forsigning ephemeral keys and for client authentication using digital signatures. This is due to thedifficulty 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 shallprovide 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 theircertification paths shall be signed using key pairs that offer at least 112 bits of security andSHA-224 or a stronger hashing algorithm. All ephemeral keys used by the client and server shalloffer at least 112 bits of security. All symmetric algorithms used to protect the TLS data shalluse keys that offer at least 112 bits of security.
The FIPS 140 validation certificate for the cryptographic module used by the server shallindicate that the random bit generator (RBG) has been validated in accordance with the SP 80090 series [8, 48, 66]. 22
The server random value, sent in the ServerHello message, contains a 4-byte timestamp 23 valueand 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. 24 The validated random number generator should be used togenerate the 4-byte timestamp of the server random value.
3.4

TLS Extension Support

Several TLS extensions are described in RFCs. This section contains recommendations for asubset 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 notlisted 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 no22 Validation will include compliance with SP 800-90C once it is available.
23 The timestamp value does not need to be correct in TLS. It can be any 4-byte value unless otherwise restricted by higher-levelor application protocols.

24 TLS 1.3 implementations include a downgrade protection mechanism embedded in the random value that overwrites the lasteight bytes of the server random value with a fixed value. When negotiating TLS 1.2, the last eight bytes of the server
random will be set to 44 4F 57 4E 47 52 44 01. When TLS 1.1 or below is negotiated, the last eight bytes of the random
value will be set to 44 4F 57 4E 47 52 44 00. This overwrite is independent of the validated random bit generator.

21

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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 theapplication or that enhance security. Extensions that are not needed should not be enabled.
3.4.1

Mandatory TLS Extensions

The server shall support the use of the following TLS extensions.
1.
2.
3.
4.
5.

Renegotiation Indication
Server Name Indication
Extended Master Secret
Signature Algorithms
Certificate Status Request extension

3.4.1.1 Renegotiation Indication

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 theconcept 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].
3.4.1.2 Server Name Indication

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 toconnect with. This extension is available in all versions of TLS. The server shall be able toprocess and respond to the server name indication extension received in a ClientHello message
as described in [29].
3.4.1.3 Extended Master Secret

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 thatthey 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
22

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

attacks by binding the master secret to a hashed log of the full handshake. The server shallsupport the use of this extension.
3.4.1.4 Signature Algorithms

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 theextension described in RFC 8446 updates the extension described in RFC 5246 by adding an
additional signature scheme.
3.4.1.5 Certificate Status Request

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. 25 Whilethe extension itself is extensible, only OCSP-type certificate status is defined in [29]. Thisextension is also called OCSP stapling.
3.4.2

Conditional TLS Extensions

Support the use of the following TLS extensions under the circumstances described in thefollowing subsections:
1. The Fallback Signaling Cipher Suite Value (SCSV) shall be supported if the server
supports versions of TLS prior to TLS 1.2 and does not support TLS 1.3.
2. The Supported Groups extension shall be supported if the server supports ephemeral
ECDH cipher suites or if the server supports TLS 1.3.
3. The Key Share extension shall be supported if the server supports TLS 1.3.
4. The EC Point Format extension shall be supported if the server supports EC cipher
suites.
5. The Multiple Certificate Status extension should be supported if status information forthe server’s certificate is available via OCSP and the extension is supported by the server
implementation.
6. The Trusted CA Indication extension shall be supported if the server communicates withmemory-constrained clients (e.g., low-memory client devices in the Internet of Things)
and the server has been issued certificates by multiple CAs.

25 In TLS 1.3, the server includes the certificate status in the Certificate message.

23

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

7. The Encrypt-then-MAC extension shall be supported if the server is configured tonegotiate CBC cipher suites.
8. The Truncated HMAC extension may be supported if the server communicates withconstrained-device clients, cipher suites that use CBC mode are supported, and the server
implementation does not support variable-length padding.
9. The Pre-Shared Key extension may be supported if the server supports TLS 1.3.
10. The Pre-Shared Key Exchange Modes extension shall be supported if the server supports
TLS 1.3 and the Pre-Shared Key extension.
11. The Supported Versions extension shall be supported if the server supports TLS 1.3.
12. The Cookie extension shall be supported if the server supports TLS 1.3.
13. The Certificate Signature Algorithms Extension shall be supported if the server supports
TLS 1.3 and should be supported for TLS 1.2.
14. The Post-handshake Client Authentication extension may be supported if the server
supports TLS 1.3.
15. The Signed Certificate Timestamps extension should be supported if the server’s
certificate was issued by a publicly trusted CA and the certificate does not include a
Signed Certificate Timestamps List extension.
3.4.2.1 Fallback Signaling Cipher Suite Value (SCSV)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, describedin 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 notsupported, the fallback SCSV shall be supported.
3.4.2.2 Supported Groups

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 P384 (secp384r1), shall be supported as described in RFC 8422 [52]. Additional NIST-24

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

recommended elliptic curves are listed in SP 800-56A, Appendix D [6]. Finite field groups thatare approved for TLS in SP 800-56A, Appendix D may be supported.
3.4.2.3 Key Share

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].
3.4.2.4 Supported Point Formats

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 shallprocess 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].
3.4.2.5 Multiple Certificate Status

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 thecertificates 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]. Serversthat have this capability and have certificates issued by CAs that support OCSP should be
configured to support this extension.
3.4.2.6 Trusted CA Indication

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 andpossesses a small number of root CA keys. Servers that communicate with memory-constrainedclients and that have been issued certificates by multiple CAs shall be able to process andrespond to the trusted CA indication extension received in a ClientHello message as described in
[29].

25

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

3.4.2.7 Encrypt-then-MAC

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 ofoperations used in TLS versions 1.0, 1.1, and 1.2. The Encrypt-then-MAC extension alters theorder 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. Serversthat are configured to negotiate CBC cipher suites shall support this extension as described in[33].
3.4.2.8 Truncated HMAC

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.
3.4.2.9 Pre-Shared Key

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-sharedkeys 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 useof pre-shared keys that are established out-of-band.
3.4.2.10 Pre-Shared Key Exchange Modes

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 thelist 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 thisextension.

26

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

3.4.2.11 Supported Versions

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

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].
3.4.2.13 Certificate Signature Algorithms

Applies to TLS versions: 1.2, 1.3
The Certificate Signature Algorithms extension (signature_algorithms_cert) indicates thesignature 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.
3.4.2.14 Post-handshake Client Authentication

Applies to TLS version 1.3
The Post-handshake Client Authentication extension (post_handshake_auth) allows the server torequest client authentication after the handshake is complete. TLS servers that support TLS 1.3
may support this extension.
3.4.2.15 Signed Certificate Timestamps

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 impactof 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 publiccertificate auditing. Certificate logs are cryptographically assured records of certificates that areopen 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 asverify the integrity and consistency of logs.

27

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

Evidence that the server’s certificate has been submitted to Certificate Transparency logs may beprovided 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.
3.4.3

Discouraged TLS Extensions

The following extensions should not be used:
1. Client Certificate URL
2. Early Data Indication
The Raw Public Keys extension shall not be supported.
3.4.3.1 Client Certificate URL

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, becomessubject 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 thisextension 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].
3.4.3.2 Early Data Indication

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 thisearly 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, theserver 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).

28

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

3.4.3.3 Raw Public Keys

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 tocertificate-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-ofband binding between a public key and entity must be used.
3.5

Client Authentication

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 cryptographicallyauthenticate the client. 26 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 totake 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 “handshakefailure” alert when a client certificate is requested and the client does not have a suitable
certificate.
3.5.1

Path Validation

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 thecertification path shall be validated using the Online Certificate Status Protocol (OCSP) or acertificate revocation list (CRL). OCSP checking shall be in compliance with RFC 6960 [63].

26 The CertificateVerify handshake message is sent to explicitly verify a client certificate that has a signing capability. In TLS 1.1(and TLS 1.0), this message uses SHA-1 to generate a signature on all handshake messages that came before it. SP 800131A [10] states that the use of SHA-1 for digital signature generation is disallowed after 2013. Even if a collision is found,the client must use its private key to authenticate itself by signing the hash. Due to the client random and server random
values, the server, the client, or a third party cannot use a colliding set of messages to masquerade as the client or server infuture connections. Any modification to this message, preceding messages, or subsequent messages will ultimately result ina failed connection. Therefore, SHA-1 is allowed for generating digital signatures in the TLS CertificateVerify message.

29

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSRevocation 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, areaccepted.
Not all commercial products may support the public-key certification path validation andcertificate policy processing rules listed and cited above. When implementing client
authentication, federal agencies shall either use the commercial products that meet theserequirements or augment commercial products to meet these requirements.
The server shall be able to provide the client certificate and the certificate policies for which theclient certification path is valid to consuming applications in order to support access control
decisions.
3.5.2

Trust Anchor StoreHaving an excessive number of trust anchors installed in the TLS application can expose theapplication to all the PKIs emanating from those trust anchors. The best way to minimize theexposure 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 certificatebased 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 requiredfor client authentication. Some specific enterprise and/or PKI service trust anchors may need tobe 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 theFederal Common Policy Root) should be sufficient to build a certification path to the clientcertificates.
3.5.3

Checking the Client Key Size

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 andalgorithm 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
30

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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 theclient key size.
3.5.4

Server Hints List

Clients may use the list of trust anchors sent by the server in the CertificateRequest message todetermine if the client’s certification path terminates at one of these trust anchors. The list sentby 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., theserver PKI domain and the client PKI domain) or via transitive cross-certification (i.e., throughcross-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 listor 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. 27 In other words,
the server shall continue to only populate its trust anchor store with the trust anchor of theserver’s PKI domain and the domains it needs to trust directly for client authentication. Note thatthe distinction between the server hints list and the server’s own trust store is as follows: 1) thehints 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.
3.6

Session Resumption and Early Data

Previous TLS sessions can be resumed, allowing for a connection to be established using anabbreviated 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 asession 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 theuse of such mechanisms, it is important to understand the security impact if long-term or sharedkeys 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. 28 The TLS 1.3
specification describes two mechanisms to mitigate threats introduced by 0-RTT data. One of

27 Depending on the server and client trust anchors, the two lists could be identical, could have some trust anchors in common, or

have no trust anchors in common.

28 TLS does not inherently provide replay protection for 0-RTT data.

31

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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 asession database must be shared between servers. ClientHello recording is a second mechanismthat defends against replay attacks by recording a unique value derived from the ClientHello andrejecting 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 theserver does allow 0-RTT data, then the server should use the single-use ticket mechanism inaccordance with RFC 8446 (see Section 8 of [57]).
3.7

Compression Methods

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

Operational Considerations

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. 29 Where the server relies on a FIPS 140
Level 1 cryptographic module, the software and private key shall be protected using theoperating system identification, authentication, and access control mechanisms. In some highly
sensitive applications, server private keys may require protection using a FIPS 140 Level 2 orhigher 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.

29 A secure operating system contains and uses the following features: operating system protection from applications andprocesses, operating system mediated isolation among applications and processes, user identification and authentication,access control based on authenticated user identity, and event logging of security-relevant activities.

32

NIST SP 800-52 REV. 2

4

GUIDELINES FOR TLS IMPLEMENTATIONSMinimum Requirements for TLS Clients

This section provides a minimum set of requirements that a TLS client must meet in order toadhere 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 areenabled or, in some cases, configured appropriately if present.
4.1

Protocol Version Support

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 shallsupport 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 forinteroperability.
4.2

Client Keys and CertificatesSome applications may require client authentication. For TLS, this can be achieved by
performing mutual authentication using certificates.
4.2.1

Client Certificate Profile

When certificate-based client authentication is needed, the client shall be configured with acertificate 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 thisspecification, the TLS client certificate shall be an X.509 version 3 certificate; both the publickey contained in the certificate and the signature shall provide at least 112 bits of security. If theclient supports TLS versions prior to TLS 1.2, the certificate should be signed with an algorithm
that is consistent with the public key: 30•••

Certificates containing RSA (signature), ECDSA, or DSA public keys should be signedwith those same signature algorithms, respectively;
Certificates containing Diffie-Hellman certificates should be signed with DSA; andCertificates containing ECDH public keys should be signed with ECDSA.

30 This recommendation is an artifact of requirements in TLS 1.0 and 1.1.

33

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

The client certificate profile is listed in Table 4-1. In the absence of an agency-specific clientcertificate profile, this profile should be used for client certificates.
Table 4-1: TLS Client Certificate Profile
Field

CriticalValue

Description

VersionN/A

2

Version 3

Serial Number

N/A

Unique positive integer

Must be uniqueIssuer Signature Algorithm

N/A

Values by CA key type:sha256WithRSAEncryption {1 2 840
113549 1 1 11}, or stronger

CA with RSA key

id-RSASSA-PSS { 1 2 840 113549 1 1
10}CA with RSA key

ecdsa-with-SHA256 {1 2 840 10045 4 32}, or stronger

CA with elliptic curve key

id-dsa-with-sha256 {2 16 840 1 101 3 4 32}, or stronger

CA with DSA key

Issuer Distinguished Name

N/A

Unique X.500 Issuing CA DN

A single value should be encoded in each
RDN. All attributes that are of
directoryString type should be encoded asa printable string.

Validity Period

N/A

3 years or lessDates through 2049 expressed in UTCTime

Subject Distinguished Name

N/A

Unique X.500 subject DN per agency
requirements

A single value should be encoded in each
RDN. All attributes that are of
directoryString type should be encoded asa printable string.

Subject Public Key
Information

N/A

Values by certificate type:rsaEncryption {1 2 840 113549 1 1 1}

RSA signature certificate
2048-bit RSA key modulus, or otherapproved lengths as defined in [45]and [5]Parameters: NULL

ecPublicKey {1 2 840 10045 2 1}

ECDSA signature certificate or ECDH
certificate
Parameters: namedCurve OID for names
curve specified in SP 800-186. 31 The curveshould be P-256 or P-384
SubjectPublic Key: Uncompressed EC
Point.

id-dsa {1 2 840 10040 4 1}

DSA signature certificate
Parameters: p, q, g

dhpublicnumber {1 2 840 10046 2 1}

DH certificate
Parameters: p, g, q

Issuer’s Signature

N/A

Same value as in Issuer Signature
Algorithm

Extensions

31 The recommended elliptic curves now listed in FIPS 186-4 [45] will be moved to SP 800-186. Until SP 800-186 is published,

the recommended elliptic curves should be taken from FIPS 186-4.

34

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

Authority Key IdentifierNo

Octet String

Same as subject key identifier in issuing
CA certificate

Field

CriticalValue

Description

Subject Key IdentifierNo

Octet String

Same as in PKCS-10 request or calculatedby the issuing CA

Key Usage

Yes

digitalSignature

RSA certificate, DSA certificate, ECDSA
certificate

keyAgreement

ECDH certificate, DH certificate

Extended Key UsageNo

id-kp-clientAuth {1 3 6 1 5 5 7 3 2}

RequiredanyExtendedKeyUsage {2 5 29 37 0}

The anyExtendedKeyUsage OID should bepresent if the extended key usage extension
is included, but there is no intention to limit
the types of applications with which thecertificate may be used (e.g., the certificate
is a general-purpose authentication
certificate).

Prohibited: Issuer DN, Serial Number tuple

Prohibited: all others unless consistent withkey usage extension
Certificate Policies

No

Per issuer’s X.509 certificate policy

Subject Alternative NameNo

RFC 822 e-mail address, Universal
Principal Name (UPN), DNS Name,
and/or others

Optional

Authority Information AccessNo

id-ad-caIssuers

Required. Access method entry contains
HTTP URL for certificates issued to
issuing CA

id-ad-ocsp

Optional. Access method entry contains
HTTP URL for the issuing CA OCSP
responder

See comments

Optional: HTTP value in distributionPoint
field pointing to a full and complete CRL.

CRL Distribution Points

No

Prohibited: reasons and cRLIssuer fields,
and nameRelativetoCRLIssuer CHOICE

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 theuse 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 includedin the certificates to be used for TLS client authentication and should be omitted from any othercertificates.
Client certificates are also filtered by TLS clients on the basis of an ability to build a path to oneof the trust anchors in the hints list sent by the server as described in Section 3.5.4.
4.2.2

Obtaining Revocation Status Information for the Server Certificate

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

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

1. OCSP response or responses in the server’s CertificateStatus message ([29], [54]) (orCertificate message in TLS 1.3);
2. Certificate Revocation List (CRL) or OCSP response in the client’s local certificate store;
3. OCSP response from a locally configured OCSP responder;
4. OCSP response from the OCSP responder location identified in the OCSP field in the
Authority Information Access extension in the server certificate; or
5. CRL from the CRL Distribution Point extension in the server certificate.
When the server does not provide the revocation status, the local certificate store does not havethe 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, theclient 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 madeaccording to agency policy.
4.2.3

Client Public-Key Certificate Assurance

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. PIVAuthentication 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 theFederal Bridge Certification Authority [68]. Depending on the requirements of the server-side
application, other certificate policies may also be acceptable. Guidance regarding othercertificate policies is outside the scope of these guidelines.
4.3

Cryptographic Support

4.3.1

Cipher Suites

The acceptable cipher suites for a TLS client are the same as those for a TLS server. Generalpurpose 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) shallhave 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

32 The cipher suite requirement for clients is weaker than for servers because many clients, such as web browsers, may not allow

the same level of configuration as servers.

36

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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 shallcompute 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.
4.3.2

Validated Cryptography

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.
4.4

TLS Extension Support

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

Mandatory TLS Extensions

The client shall be configured to use the following extensions:
1.
2.
3.
4.
5.

Renegotiation Indication
Server Name Indication
Extended Master Secret
Signature Algorithms
Certificate Status Request

4.4.1.1 Renegotiation Indication

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].
4.4.1.2 Server Name Indication

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 capableof including this extension in a ClientHello message as described in RFC 6066 [29].

37

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

4.4.1.3 Extended Master Secret

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 shallsupport this extension.
4.4.1.4 Signature Algorithms

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 aredescribed 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 describedin RFC 5246 by adding an additional signature scheme.
4.4.1.5 Certificate Status Request

Applies to TLS versions: 1.0, 1.1, 1.2, 1.3
The client shall include the “status_request” extension in the ClientHello message.
4.4.2

Conditional TLS Extensions

A TLS client supports the following TLS extensions under the circumstances described:
1. The Fallback Signaling Cipher Suite Value (SCSV) shall be supported if the client
supports versions of TLS prior to TLS 1.2 and does not support TLS 1.3.
2. The Supported Groups extension shall be supported if the client supports ephemeral
ECDH cipher suites or if the client supports TLS 1.3.
3. The Key Share extension shall be supported if the client supports TLS 1.3.
4. The EC Point Format TLS extension shall be supported if the client supports EC cipher
suite(s).
5. The Multiple Certificate Status extension should be enabled if the extension is supportedby the client implementation.
6. The Trusted CA Indication extension should be supported by clients that run on memoryconstrained devices where only a small number of CA root keys are stored.
7. The Encrypt-then-MAC extension shall be supported when CBC mode cipher suites are
configured.
8. The Truncated HMAC extension may be supported by clients that run on constrained
devices when variable-length padding is not supported and cipher suites that use CBC
mode are supported.
9. The Pre-Shared Key extension may be supported by TLS 1.3 clients.
10. The Pre-Shared Key Exchange Modes extension shall be supported by TLS 1.3 clientsthat support the Pre-Shared Key extension.
11. The Supported Versions extension shall be supported by TLS 1.3 clients.
38

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

12. The Cookie extension shall be supported by TLS 1.3 clients.
13. The Certificate Signature Algorithms Extension shall be supported if the client supports
TLS 1.3 and should be supported for TLS 1.2.
14. The Post-handshake Client Authentication extension may be supported if the client
supports TLS 1.3.
4.4.2.1 Fallback Signaling Cipher Suite Value (SCSV)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 afallback, and if the server supports a higher TLS version, the server returns a fatal alert. If theclient 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.
4.4.2.2 Supported Groups

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 ClientHellomessages 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.
4.4.2.3 Key Share

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].
4.4.2.4 Supported Point Formats

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].

39

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSClients that support EC cipher suites shall support the processing of at least one 33 of the EC
point formats received in the ServerHello message as described in Section 5.2 of [52].
4.4.2.5 Multiple Certificate Status

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 improveson the Certificate Status Request extension described in Section 3.4.1.5 by allowing the client torequest 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.
4.4.2.6 Trusted CA Indication

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].
4.4.2.7 Encrypt-then-MAC

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.
4.4.2.8 Truncated HMAC

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 inconjunction with variable-length padding due to attacks described by Paterson et al. [53]. Thisextension is only applicable when cipher suites that use CBC modes are supported.

33 The uncompressed point format must be supported, and all others are deprecated in TLS as described in Sections 5.1.2 of RFC

8422 [52].

40

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

4.4.2.9 Pre-Shared Key

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 establishedout-of-band, as in TLS 1.2 and prior versions, or in a previous connection, in which case they areused for session resumption. Clients that support TLS 1.3 may be configured to use thisextension in order to allow session resumption or to allow the use of pre-shared keys that are
established out-of-band.
4.4.2.10 Pre-Shared Key Exchange Modes

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 willabort the handshake. TLS clients that support TLS 1.3 and the Pre-Shared Key extension shall
implement this extension.
4.4.2.11 Supported Versions

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.
4.4.2.12 Cookie

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 shallsupport the cookie extension in accordance with RFC 8446 [57].
4.4.2.13 Certificate Signature Algorithms

Applies to TLS versions: 1.2, 1.3
The Certificate Signature Algorithms extension (signature_algorithms_cert) indicates thesignature algorithms that may be used in certificates. This allows the entity requesting acertificate (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 thisextension 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 tocertificates as well. TLS client implementations that support TLS 1.3 shall support thisextension, and it should be supported for TLS 1.2.

41

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

4.4.2.14 Post-handshake Client Authentication

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

Discouraged TLS Extensions

The following extensions should not be used:
1. Client Certificate URL
2. Early Data Indication
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.
4.5

Server Authentication

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.
4.5.1

Path Validation

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 clientsthat perform name constraint checking in order to obtain assurance that unauthorized certificatesare 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 ispresented 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.
42

NIST SP 800-52 REV. 2

4.5.2

GUIDELINES FOR TLS IMPLEMENTATIONS

Trust Anchor StoreHaving 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 theclient 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. 34 Direct trust of these certificates can expose the clients unduly to avariety 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 topromulgate 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 pathbuilding problem as discussed in Section 3.5.4.
4.5.3

Checking the Server Key Size

The only direct mechanism for a client to check if the key size presented in a server publiccertificate 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 policythat 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 andchecking. 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 amechanism 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 amechanism to do so.
The length of each write key is determined by the negotiated cipher suite. Restrictions on thelength of the shared session keys can be enforced by configuring the client to only support cipher
suites that meet the key length requirements.
4.5.4

User Interface

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 ofindicators 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 theserver 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
34 CA certificates that may be verified via cross-certification may be added to the client’s store as untrusted or intermediate

certificates. Clients use certificates that are stored as untrusted or intermediate certificates to aid in path-building but do nottreat them as trust anchors.

43

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

intended to visit the indicated website. Users should be aware that URLs can appear to belegitimate 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 shallfollow the relevant policies and procedures for protecting client authentication keys outside of
the client.
4.6

Session Resumption and Early Data

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 0RTT data.
RFC 7918 [39] describes a technique called False Start that allows a TLS 1.2 client to send earlydata. While this concept is similar to the 0-RTT data of TLS 1.3, there are differences that affectsecurity. For example, an attacker may perform downgrade attacks, both of protocol versions andcipher 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 unlessthere is a real need for it. TLS 1.2 clients shall not use False Start.
4.7

Compression Methods

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

Operational Considerations

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 andpassword) 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 operateclient systems in accordance with agency and administrator instructions.

44

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSAppendix A—Acronyms

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

IETF mnemonic for Triple Data Encryption Algorithm

AEAD
AES

Authenticated Encryption with Associated Data
Advanced Encryption Standard

CA
CBC
CCM
CRL

Certification Authority
Cipher Block Chaining
Counter with CBC-MAC
Certificate Revocation List

DES
DH
DHE
DNS
DNSSECDSADSSData Encryption Standard
Diffie-Hellman key exchange
Ephemeral Diffie-Hellman key exchange
Domain Name System
DNS Security Extensions
Digital Signature Algorithm
Digital Signature Standard (implies DSA)

EC
ECDHE
ECDSA

Elliptic Curve
Ephemeral Elliptic Curve Diffie-Hellman
Elliptic Curve Digital Signature Algorithm

FIPS

Federal Information Processing Standard

GCM

Galois Counter ModeHKDF

HMAC-based Extract-and-Expand Key Derivation Function

HMAC

Keyed-hash Message Authentication Code

IETF

Internet Engineering Task ForceKDF

Key Derivation Function

MAC

Message Authentication Code

OCSP
OID

Online Certificate Status Protocol
Object Identifier

PIV
PKCS
PKI
PRF
PSK

Personal Identity Verification
Public-Key Cryptography Standards
Public Key Infrastructure
Pseudo-random Function
Pre-Shared Key
45

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

RFC

Request for Comments

SHA
SSL

Secure Hash Algorithm
Secure Sockets Layer

TDEA

Triple Data Encryption Algorithm

TLS

Transport Layer Security

URL

Uniform Resource Locator

46

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSAppendix B—Interpreting Cipher Suite Names

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 forinterpreting the names of cipher suites for TLS 1.3. In all TLS cipher suites, the first mnemonicis 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.
••

If there is only one mnemonic, it must be PSK based on the recommendations in theseguidelines. The single mnemonic PSK indicates that the premaster secret is establishedusing only symmetric algorithms with pre-shared keys as described in RFC 4279 [30].
Pre-shared key cipher suites that are approved for use with TLS 1.2 are listed inAppendix C.
If there are two mnemonics following the protocol name, the first key exchange
mnemonic should be DH, ECDH, DHE, or ECDHE.
o When the first key exchange mnemonic is DH or ECDH, it indicates that theserver’s public key in its certificate is for either DH or ECDH key exchange, andthe second mnemonic indicates the signature algorithm that was used by theissuing CA to sign the server certificate.
o When the first key exchange mnemonic is DHE or ECDHE, it indicates thatephemeral DH or ECDH will be used for key exchange with the second
mnemonic indicating the server signature public key type that will be used toauthenticate the server’s ephemeral public key. 35

EncryptionAlg indicates the symmetric encryption algorithm and associated mode of operations.
MessageAuthenticationAlg is generally the hashing algorithm to be used for HMAC, if
applicable. 36 In cases where HMAC is not applicable (e.g., AES-GCM) or the cipher suite wasdefined after the release of the TLS 1.2 RFC, this mnemonic represents the hashing algorithm
used with the PRF.

35 In this case, the signature algorithm used by the CA to sign the certificate is not articulated in the cipher suite.
36 HMAC is not applicable when the symmetric encryption mode of operation is authenticated encryption. Note that the CCM

mode cipher suites do not specify the last mnemonic and require that SHA-256 be used for the PRF.

47

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: Ephemeral DH is used for the key
exchange. The server’s ephemeral public key is authenticated using the server’s RSA
public key. Once the handshake is completed, the messages are encrypted using AES-256
in CBC mode. SHA-256 is used for both the PRF and HMAC computations.

•

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: Ephemeral ECDH is used forthe key exchange. The server’s ephemeral public key is authenticated using the server’s
ECDSA public key. Once the handshake is completed, the messages are encrypted andauthenticated using AES-256 in GCM mode, and SHA-384 is used for the PRF. Since anauthenticated encryption mode is used, messages neither have nor require an HMAC
message authentication code.

B.2

Interpreting Cipher Suites Names in TLS 1.3

As shown in Section 3.3.1, these cipher suites have the following form:
TLS_AEAD_HASHAEAD 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:••

TLS_AES_256_GCM_SHA384: Messages are encrypted and authenticated with AES256 in GCM mode, and SHA-384 is used with the HKDF.
TLS_AES_128_CCM_SHA256: Messages are encrypted and authenticated with AES128 in CCM mode, and SHA-256 is used with the HKDF.

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

48

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSAppendix C—Pre-shared Keys

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 areused 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 withlimited 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 theserver 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 isused, the result of the Diffie-Hellman computation is combined with the pre-shared key andother 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 communicateswith non-government systems.
TLS 1.2 servers and clients using pre-shared keys may support the following cipher suites:• TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 (0x00, 0xAA)• TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 (0x00, 0xAB)• TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256 (0xC0, 0x37)• TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384 (0xC0, 0x38)• TLS_DHE_PSK_WITH_AES_128_CCM (0xC0, 0xA6)• TLS_DHE_PSK_WITH_AES_256_CCM (0xC0, 0xA7)• TLS_PSK_DHE_WITH_AES_128_CCM_8 (0xC0, 0xAA)• TLS_PSK_DHE_WITH_AES_256_CCM_8 (0xC0, 0xAB)• TLS_DHE_PSK_WITH_AES_128_CBC_SHA256 (0x00, 0xB2)• TLS_DHE_PSK_WITH_AES_256_CBC_SHA384 (0x00, 0xB3)• TLS_PSK_WITH_AES_128_GCM_SHA256 (0x00, 0xA8)• TLS_PSK_WITH_AES_256_GCM_SHA384 (0x00, 0xA9)
49

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS• TLS_PSK_WITH_AES_128_CCM (0xC0, 0xA4)• TLS_PSK_WITH_AES_256_CCM (0xC0, 0xA5)• TLS_PSK_WITH_AES_128_CCM_8 (0xC0, 0xA8)• TLS_PSK_WITH_AES_256_CCM_8 (0xC0, 0xA9)• TLS_PSK_WITH_AES_128_CBC_SHA256 (0x00, 0xAE)• TLS_PSK_WITH_AES_256_CBC_SHA384 (0x00, 0xAF)• TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA (0xC0, 0x35)• TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA (0xC0, 0x36)• TLS_DHE_PSK_WITH_AES_128_CBC_SHA (0x00, 0x90)• TLS_DHE_PSK_WITH_AES_256_CBC_SHA (0x00, 0x91)• TLS_PSK_WITH_AES_128_CBC_SHA (0x00, 0x8C)• TLS_PSK_WITH_AES_256_CBC_SHA (0x00, 0x8D)

50

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSAppendix D—RSA Key Transport

RSA key transport is a key exchange mechanism where the premaster secret is chosen by theclient, 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:
1. The client has sole responsibility for the premaster secret generation. If the client does
not have sufficient entropy to generate the premaster secret, the security of the session
will suffer.
2. It does not enable forward secrecy.
3. The padding scheme that TLS uses for this operation has a known vulnerability that
requires TLS implementations to perform attack mitigation.
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 compromiseof long-term keys from enabling the decryption of sessions. The only way to achieve thisproperty 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 amanner 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 becircumstances 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 thesecipher 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 forgeneral information on preference order.
•
•
•
•
•
•
•

TLS_RSA_WITH_AES_128_CCM (xC0, x9C)
TLS_RSA_WITH_AES_256_CCM (xC0, x9D)
TLS_RSA_WITH_AES_128_CCM_8 (xC0, xA0)
TLS_RSA_WITH_AES_256_CCM_8 (xC0, xA1)
TLS_RSA_WITH_AES_128_CBC_SHA (x00, x2F)
TLS_RSA_WITH_AES_256_CBC_SHA (x00, x35)
TLS_RSA_WITH_AES_128_CBC_SHA256 (x00, 3C)
51

NIST SP 800-52 REV. 2•••

GUIDELINES FOR TLS IMPLEMENTATIONSTLS_RSA_WITH_AES_256_CBC_SHA256 (x00, 3D)
TLS_RSA_WITH_AES_128_GCM_SHA256 (x00, x9C)
TLS_RSA_WITH_AES_256_GCM_SHA384 (x00, x9D)

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

52

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSAppendix E—Future Capabilities

This section identifies emerging concepts and capabilities that are applicable to TLS. As theseconcepts mature and commercial products are available to support them, these guidelines will berevised 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 publictrust root and issuing CA infrastructure to issue TLS server certificates for federal web serviceson the public Internet. The intent is for this new root to be included in all of the commonly usedtrust 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 athttps://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 aresource 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:
1. The DNS record contains an end-entity certificate. In addition to the server public-key
certificate validation, as specified in Section 4.5, the client verifies that the TLS server
certificate matches the certificate provided in the DNS records.
2. The DNS record contains a domain-issued end-entity certificate. 37 The client can use thecertificate if it verifies that the TLS server certificate matches the one provided in the
DNS records (i.e., the client forgoes server public-key certificate validation as specified
in Section 4.5).
3. The DNS record contains a CA certificate. In addition to the server public-key certificate
validation, as specified in Section 4.5, the client verifies that the certification path for the
TLS server certificate includes the CA certificate provided in the DNS records.
4. The DNS record contains a certificate that is to be used as a trust anchor. The client
validates the TLS server certificate, as specified in Section 4.5, using the trust anchor
provided in the DNS records instead of the trust anchors in the client’s local trust anchor
store.

37 In this context, a “domain-issued” certificate is one that is issued by the domain name administrator without involving a third-

party CA. It corresponds to usage case 3 in Section 2.1.1 of RFC 6698.

53

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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) tothe server in plain text. This means that an eavesdropper can determine the domain name of theserver to which a client is connecting even if the eavesdropper was unable to listen in on theclient’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 thisinformation would not be accessible to eavesdroppers [35, 58]. Enabling support for thismechanism in TLS clients and servers would provide an additional level of privacy to TLS
clients.

54

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSAppendix F—Determining the Need for TLS 1.0 and 1.1

Enabling TLS 1.0 or 1.1 when they are not needed may leave systems and users vulnerable toattacks (such as the BEAST attack and the Klima attack [65]). However, disabling older versionsof TLS when there is a need may deny access to users who are unable to install or upgrade to aclient 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 thecontext 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 fromusing 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 interms of accessibility. The decision to support TLS 1.0 or 1.1 must be technically assessed on acase-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 thisdetermination. 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 supportingor not supporting TLS versions prior to TLS 1.2. For example, DAP data on visitor OS andbrowser 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 beunnecessary for servers to support TLS 1.1. Administrators can determine whether TLS 1.1 isneeded by assessing whether it must support connections with clients where TLS 1.1 is thehighest version available.

55

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSAppendix G—References[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 PairWise 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/eu13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-wp.pdf
56

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS[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 Issuanceand Management of Publicly-Trusted Certificates. Available athttps://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 forComments (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:
Application-Specific Key Management Guidance. (National Institute of Standards andTechnology, Gaithersburg, MD), NIST Special Publication (SP) 800-57 Part 3, Rev. 1.
https://doi.org/10.6028/NIST.SP.800-57pt3r1
57

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS[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 forComments (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 forComments (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 andTechnology, 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 andTechnology, 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
58

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS

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-ietftls-sni-encryption/[36]

Joint Task Force Transformation Initiative (2013) Security and Privacy Controls forFederal Information Systems and Organizations. (National Institute of Standards andTechnology, 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 forComments (RFC) 5869. https://doi.org/10.17487/RFC5869[38]

Langley A, (2014) The POODLE bites again. Available athttps://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

59

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS[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 forComments (RFC) 6961. https://doi.org/10.17487/RFC6961[55]

Polk T, McKay KA, Chokhani S (2014) Guidelines for the Selection, Configuration, andUse 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

60

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS[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-tlsesni/[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/eko8CRIME.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
61

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONS[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 athttps://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 andCertificate Revocation List (CRL) Profile. (Internet Engineering Task Force (IETF)),
IETF Request for Comments (RFC) 6818. https://doi.org/10.17487/RFC6818

62

NIST SP 800-52 REV. 2

GUIDELINES FOR TLS IMPLEMENTATIONSAppendix H—Revision History
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, andTLS 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 waswithdrawn.
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 withthis 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 80057 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 overprevious 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 signaturealgorithms can sign which key types in certificates.

63