idnits 2.17.1 draft-cooley-cnsa-dtls-tls-profile-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 20, 2021) is 1191 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Cooley 3 Internet-Draft NSA 4 Intended status: Informational January 20, 2021 5 Expires: July 24, 2021 7 Commercial National Security Algorithm (CNSA) Suite Profile for TLS and 8 DTLS 1.2 and 1.3 9 draft-cooley-cnsa-dtls-tls-profile-07 11 Abstract 13 This document defines a base profile for TLS protocol versions 1.2 14 and 1.3, as well as DTLS protocol versions 1.2 and 1.3 for use with 15 the United States Commercial National Security Algorithm (CNSA) 16 Suite. 18 The profile applies to the capabilities, configuration, and operation 19 of all components of US National Security Systems that use TLS or 20 DTLS. It is also appropriate for all other US Government systems 21 that process high-value information. 23 The profile is made publicly available here for use by developers and 24 operators of these and any other system deployments. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 24, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. The Commercial National Security Algorithm Suite . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. CNSA Suite . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. CNSA (D)TLS Key Establishment Algorithms . . . . . . . . 5 65 4.2. CNSA TLS Authentication . . . . . . . . . . . . . . . . . 6 66 5. CNSA Compliance and Interoperability Requirements . . . . . . 6 67 5.1. Acceptable ECC Curves . . . . . . . . . . . . . . . . . . 6 68 5.2. Acceptable RSA Schemes, Parameters and Checks . . . . . . 6 69 5.3. Acceptable Finite Field Groups . . . . . . . . . . . . . 7 70 5.4. Certificates . . . . . . . . . . . . . . . . . . . . . . 8 71 6. (D)TLS 1.2 Requirements . . . . . . . . . . . . . . . . . . . 8 72 6.1. The extended_master_secret Extension . . . . . . . . . . 8 73 6.2. The signature_algorithms Extension . . . . . . . . . . . 9 74 6.3. The signature_algorithms_cert Extension . . . . . . . . . 9 75 6.4. The CertificateRequest Message . . . . . . . . . . . . . 10 76 6.5. The CertificateVerify Message . . . . . . . . . . . . . . 10 77 6.6. The Signature in the ServerKeyExchange Message . . . . . 10 78 6.7. Certificate Status . . . . . . . . . . . . . . . . . . . 10 79 7. (D)TLS 1.3 Requirements . . . . . . . . . . . . . . . . . . . 10 80 7.1. The "signature_algorithms" Extension . . . . . . . . . . 11 81 7.2. The "signature_algorithms_cert" Extension . . . . . . . . 11 82 7.3. The "early_data" Extension . . . . . . . . . . . . . . . 12 83 7.4. Resumption . . . . . . . . . . . . . . . . . . . . . . . 12 84 7.5. Certificate Status . . . . . . . . . . . . . . . . . . . 12 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 89 10.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 This document specifies a profile of TLS version 1.2 [RFC5246] and 95 TLS version 1.3 [RFC8446], as well as DTLS version 1.2 [RFC6347] and 96 DTLS version 1.3 [ID.dtls13] for use by applications that support the 97 National Security Agency's (NSA) Commercial National Security 98 Algorithm (CNSA) Suite [CNSA]. The profile applies to the 99 capabilities, configuration, and operation of all components of US 100 National Security Systems [SP80059]. It is also appropriate for all 101 other US Government systems that process high-value information. It 102 is made publicly available for use by developers and operators of 103 these and any other system deployments. 105 This document does not define any new cipher suites; instead, it 106 defines a CNSA compliant profile of TLS and DTLS, and the cipher 107 suites defined in [RFC5288], [RFC5289], and [RFC8446]. This profile 108 uses only algorithms in the CNSA Suite. 110 The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as 111 well as the DTLS 1.2 and 1.3 protocol specifications: [RFC5246], 112 [RFC6347], [RFC8446], and [ID.dtls13]. All MUST-level requirements 113 from the protocol documents apply throughout this profile; they are 114 generally not repeated. This profile contains changes that elevate 115 some SHOULD-level options to MUST-level; this profile also contains 116 changes that elevate some MAY-level options to SHOULD-level or MUST- 117 level. All options that are not mentioned in this profile remain at 118 their original requirement level. 120 2. The Commercial National Security Algorithm Suite 122 The National Security Agency (NSA) profiles commercial cryptographic 123 algorithms and protocols as part of its mission to support secure, 124 interoperable communications for US Government National Security 125 Systems. To this end, it publishes guidance both to assist with the 126 US Government transition to new algorithms, and to provide vendors - 127 and the Internet community in general - with information concerning 128 their proper use and configuration. 130 Recently, cryptographic transition plans have become overshadowed by 131 the prospect of the development of a cryptographically-relevant 132 quantum computer. NSA has established the CNSA Suite to provide 133 vendors and IT users near-term flexibility in meeting their 134 Information Assurance (IA) interoperability requirements. The 135 purpose behind this flexibility is to avoid having vendors and 136 customers make two major transitions in a relatively short timeframe, 137 as we anticipate a need to shift to quantum-resistant cryptography in 138 the near future. 140 NSA is authoring a set of RFCs, including this one, to provide 141 updated guidance concerning the use of certain commonly available 142 commercial algorithms in IETF protocols. These RFCs can be used in 143 conjunction with other RFCs and cryptographic guidance (e.g., NIST 144 Special Publications) to properly protect Internet traffic and data- 145 at-rest for US Government National Security Systems. 147 3. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 "ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital 156 Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), 157 respectively. ECDSA and ECDH are used with the NIST P-384 curve 158 (which is based on a 384-bit prime modulus) and the SHA-384 hash 159 function. Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman 160 (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH 161 are used with a 3072-bit or 4096-bit modulus. When RSA is used for 162 digital signature, it is used with the SHA-384 hash function. 164 Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS 165 versions 1.2 and 1.3 collectively as (D)TLS. 167 4. CNSA Suite 169 [CNSA] approves the use of both finite field and elliptic curve 170 versions of the DH key agreement algorithm, as well as RSA-based key 171 establishment. [CNSA] also approves certain versions of the RSA and 172 elliptic curve digital signature algorithms. The approved encryption 173 techniques include the Advanced Encryption Standard (AES) used with a 174 256-bit key in an Authenticated Encryption with Associated Data 175 (AEAD) mode. 177 In particular, CNSA includes the following: 179 Encryption: 181 AES [AES] (with key size 256 bits), operating in Galois/Counter 182 Mode (GCM) [GCM] 184 Digital Signature: 186 ECDSA [DSS] (using the NIST P-384 elliptic curve) 187 RSA [DSS] (with a modulus of 3072 bits or 4096 bits) 189 Key Establishment (includes key agreement and key transport): 191 ECDH [PWKE-A] (using the NIST P-384 elliptic curve) 193 DH [PWKE-A] (with a prime modulus of 3072 or 4096 bits) 195 RSA [PWKE-B] (with a modulus of 3072 or 4096 bits, but only in 196 (D)TLS 1.2) 198 [CNSA] also approves the use of SHA-384 [SHS] for the hash algorithm 199 for mask generation, signature generation, Pseudo Random Function 200 (PRF) in TLS 1.2 and HMAC-based key derivation function (HKDF) in TLS 201 1.3. 203 4.1. CNSA (D)TLS Key Establishment Algorithms 205 The following combination of algorithms and key sizes are used in 206 CNSA (D)TLS: 208 AES with 256-bit key, operating in GCM mode 210 ECDH [PWKE-A] using the Ephemeral Unified Model Scheme with 211 cofactor set to 1 (see Section 6.1.2.2 in [PWKE-A]) 213 TLS PRF/HKDF with SHA-384 [SHS] 215 Or 217 AES with 256-bit key, operating in GCM mode 219 RSA key transport using 3072-bit or 4096-bit modulus 220 [PWKE-B][RFC8017] 222 TLS PRF/HKDF with SHA-384 [SHS] 224 Or 226 AES with 256-bit key, operating in GCM mode 228 DH using dhEphem with domain parameters specified below in 229 Section 5.3 (see Section 6.1.2.1 in [PWKE-A]) 231 TLS PRF/HKDF with SHA-384 [SHS] 233 The specific CNSA compliant cipher suites are listed in Section 5. 235 4.2. CNSA TLS Authentication 237 For server and/or client authentication, CNSA (D)TLS MUST generate 238 and verify either ECDSA signatures or RSA signatures. 240 In all cases, the client MUST authenticate the server. The server 241 MAY also authenticate the client, as needed by the specific 242 application. 244 The public keys used to verify these signatures MUST be contained in 245 a certificate, see Section 5.4 for more information. 247 5. CNSA Compliance and Interoperability Requirements 249 CNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA 250 compliant system. CNSA (D)TLS servers and clients MUST implement and 251 use either (D)TLS version 1.2 [RFC5246][RFC6347] or (D)TLS version 252 1.3 [RFC8446][ID.dtls13]. 254 5.1. Acceptable ECC Curves 256 The elliptic curves used in the CNSA Suite appear in the literature 257 under two different names [DSS] [SECG]. For the sake of clarity, 258 both names are listed below: 260 Curve NIST name SECG name 261 -------------------------------- 262 P-384 nistp384 secp384r1 264 [RFC8422] defines a variety of elliptic curves. CNSA (D)TLS 265 connections MUST use secp384r1 (also called nistp384) and the 266 uncompressed form MUST be used, as required by [RFC8422] and 267 [RFC8446]. 269 Key pairs MUST be generated following Section 5.6.1.2 of [PWKE-A]. 271 5.2. Acceptable RSA Schemes, Parameters and Checks 273 [CNSA] specifies a minimum modulus size of 3072 bits; however, only 274 two modulus sizes (3072 bits and 4096 bits) are supported by this 275 profile. 277 For (D)TLS 1.2: 279 For certificate signature, RSASSA-PKCS1-v1.5 [RFC8017] MUST be 280 supported, and RSASSA-PSS [DSS] SHOULD be supported. 282 For signatures in TLS handshake messages RSASSA-PKCS1-v1.5 283 [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be 284 supported. 286 For key transport, RSAES-PKCS1-v1.5 [RFC8017] MUST be 287 supported. 289 For (D)TLS 1.3: 291 For certificate signature, RSASSA-PKCS1-v1.5 [RFC8017] MUST be 292 supported, and RSASSA-PSS [DSS] SHOULD be supported. 294 For signatures in TLS handshake messages RSASSA-PSS [DSS] MUST 295 be supported. 297 For key transport, TLS 1.3 does not support RSA key transport. 299 For all versions of (D)TLS: 301 RSA exponent e MUST satisfy 2^16. 589 [CNSA] Committee for National Security Systems, "Use of Public 590 Standards for Secure Information Sharing", CNSSP 15, 591 October 2016, 592 . 594 [DSS] National Institute of Standards and Technology, "Digital 595 Signature Standard (DSS)", NIST Federal Information 596 Processing Standard 186-4, July 2013, 597 . 600 [GCM] National Institute of Standards and Technology, 601 "Recommendation for Block Cipher Modes of Operation: 602 Galois/Counter Mode (GCM) and GMAC", NIST Special 603 Publication 800-38D, November 2007, 604 . 607 [ID.dtls13] 608 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 609 Datagram Transport Layer Security (DTLS) Protocol Version 610 1.3", May 2020, 611 . 613 Work in progress. 615 [PWKE-A] National Institute of Standards and Technology, 616 "Recommendation for Pair-Wise Key Establishment Schemes 617 Using Discrete Logarithm Cryptography", NIST Special 618 Publication 800-56A, Revision 3, April 2018, 619 . 622 [PWKE-B] National Institute of Standards and Technology, 623 "Recommendation for Pair-Wise Key Establishment Schemes 624 Using Integer Factorization Cryptography", NIST Special 625 Publication 800-56B, Revision 2, March 2019, 626 . 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, 631 DOI 10.17487/RFC2119, March 1997, 632 . 634 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 635 (TLS) Protocol Version 1.2", RFC 5246, 636 DOI 10.17487/RFC5246, August 2008, 637 . 639 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 640 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 641 DOI 10.17487/RFC5288, August 2008, 642 . 644 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 645 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 646 DOI 10.17487/RFC5289, August 2008, 647 . 649 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 650 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 651 January 2012, . 653 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 654 Langley, A., and M. Ray, "Transport Layer Security (TLS) 655 Session Hash and Extended Master Secret Extension", 656 RFC 7627, DOI 10.17487/RFC7627, September 2015, 657 . 659 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 660 Ephemeral Parameters for Transport Layer Security (TLS)", 661 RFC 7919, DOI 10.17487/RFC7919, August 2016, 662 . 664 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 665 "PKCS #1: RSA Cryptography Specifications Version 2.2", 666 RFC 8017, DOI 10.17487/RFC8017, November 2016, 667 . 669 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 670 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 671 May 2017, . 673 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 674 Curve Cryptography (ECC) Cipher Suites for Transport Layer 675 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 676 DOI 10.17487/RFC8422, August 2018, 677 . 679 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 680 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 681 . 683 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 684 Algorithm (CNSA) Suite Certificate and Certificate 685 Revocation List (CRL) Profile", RFC 8603, 686 DOI 10.17487/RFC8603, May 2019, 687 . 689 [SHS] National Institute of Standards and Technology, "Secure 690 Hash Standard (SHS)", NIST Federal Information Processing 691 Standard 180-4, August 2015, 692 . 695 10.2. Informative References 697 [SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain 698 Parameters", February 2010, 699 . 701 [SP80059] National Institute of Standards and Technology, "Guideline 702 for Identifying an Information System as a National 703 Security System", Special Publication 800 59, August 2003, 704 . 707 Author's Address 709 Dorothy Cooley 710 National Security Agency 712 Email: decoole@nsa.gov