idnits 2.17.1 draft-cooley-cnsa-dtls-tls-profile-04.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 (July 31, 2020) is 1364 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 July 31, 2020 5 Expires: February 1, 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-04 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 February 1, 2021. 43 Copyright Notice 45 Copyright (c) 2020 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] and [RFC5289]. This profile uses only 108 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) 197 [CNSA] also approves the use of SHA-384 [SHS] for the hash algorithm 198 for mask generation, signature generation, Pseudo Random Function 199 (PRF) in TLS 1.2 and HMAC-based key derivation function (HKDF) in TLS 200 1.3. 202 4.1. CNSA (D)TLS Key Establishment Algorithms 204 The following combination of algorithms and key sizes are used in 205 CNSA (D)TLS: 207 AES with 256-bit key, operating in GCM mode 209 ECDH [PWKE-A] using the Ephemeral Unified Model Scheme with 210 cofactor set to 1 (see Section 6.1.2.2 in [PWKE-A]) 212 TLS PRF/HKDF with SHA-384 [SHS] 214 Or 216 AES with 256-bit key, operating in GCM mode 218 RSA key transport using 3072-bit or 4096-bit modulus 219 [PWKE-B][RFC8017] 221 TLS PRF/HKDF with SHA-384 [SHS] 223 Or 225 AES with 256-bit key, operating in GCM mode 227 DH using dhEphem with domain parameters specified below in 228 Section 5.3 (see Section 6.1.2.1 in [PWKE-A]) 230 TLS PRF/HKDF with SHA-384 [SHS] 232 The specific CNSA compliant cipher suites are listed in Section 5. 234 4.2. CNSA TLS Authentication 236 For server and/or client authentication, CNSA (D)TLS MUST generate 237 and verify either ECDSA signatures or RSA signatures. 239 In all cases, the client MUST authenticate the server. The server 240 MAY also authenticate the client, as needed by the specific 241 application. 243 The public keys used to verify these signatures MUST be contained in 244 a certificate, see Section 5.4 for more information. 246 5. CNSA Compliance and Interoperability Requirements 248 CNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA 249 compliant system. CNSA (D)TLS servers and clients MUST implement and 250 use either (D)TLS version 1.2 [RFC5246][RFC6347] or (D)TLS version 251 1.3 [RFC8446][ID.dtls13]. 253 5.1. Acceptable ECC Curves 255 The elliptic curves used in the CNSA Suite appear in the literature 256 under two different names [DSS] [SECG]. For the sake of clarity, 257 both names are listed below: 259 Curve NIST name SECG name 260 -------------------------------- 261 P-384 nistp384 secp384r1 263 [RFC8422] defines a variety of elliptic curves. CNSA (D)TLS 264 connections MUST use secp384r1(24) (also called nistp384) and the 265 uncompressed(0) form MUST be used, as required by [RFC8422] and 266 [RFC8446]. 268 Key pairs MUST be generated following Section 5.6.1.2 of [PWKE-A]. 270 5.2. Acceptable RSA Schemes, Parameters and Checks 272 [CNSA] specifies a minimum modulus size of 3072 bits; however, only 273 two modulus sizes (3072 bits and 4096 bits) are supported by this 274 profile. 276 For (D)TLS 1.2: 278 For certificate signature, RSASSA-PKCS1-v1.5 [RFC8017] MUST be 279 supported, and RSASSA-PSS [DSS] SHOULD be supported. 281 For signatures in TLS handshake messages RSASSA-PKCS1-v1.5 282 [RFC8017] MUST be supported, and RSASSA-PSS [DSS] SHOULD be 283 supported. 285 For key transport, RSAES-PKCS1-v1.5 [RFC8017] MUST be 286 supported. 288 For (D)TLS 1.3: 290 For certificate signature, RSASSA-PKCS1-v1.5 [RFC8017] MUST be 291 supported, and RSASSA-PSS [DSS] SHOULD be supported. 293 For signatures in TLS handshake Messages RSASSA-PSS [DSS] MUST 294 be supported. 296 For key transport, TLS 1.3 does not support RSA key transport. 298 For all versions of (D)TLS: 300 RSA exponent e MUST satisfy 2^16. 585 [CNSA] Committee for National Security Systems, "Use of Public 586 Standards for Secure Information Sharing", CNSSP 15, 587 October 2016, 588 . 590 [DSS] National Institute of Standards and Technology, "Digital 591 Signature Standard (DSS)", NIST Federal Information 592 Processing Standard 186-4, July 2013, 593 . 596 [GCM] National Institute of Standards and Technology, 597 "Recommendation for Block Cipher Modes of Operation: 598 Galois/Counter Mode (GCM) and GMAC", NIST Special 599 Publication 800-38D, November 2007, 600 . 603 [ID.dtls13] 604 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 605 Datagram Transport Layer Security (DTLS) Protocol Version 606 1.3", May 2020, 607 . 609 Work in progress. 611 [PWKE-A] National Institute of Standards and Technology, 612 "Recommendation for Pair-Wise Key Establishment Schemes 613 Using Discrete Logarithm Cryptography", NIST Special 614 Publication 800-56A, Revision 3, April 2018, 615 . 618 [PWKE-B] National Institute of Standards and Technology, 619 "Recommendation for Pair-Wise Key Establishment Schemes 620 Using Integer Factorization Cryptography", NIST Special 621 Publication 800-56B, Revision 2, March 2019, 622 . 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, 627 DOI 10.17487/RFC2119, March 1997, 628 . 630 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 631 (TLS) Protocol Version 1.2", RFC 5246, 632 DOI 10.17487/RFC5246, August 2008, 633 . 635 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 636 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 637 DOI 10.17487/RFC5288, August 2008, 638 . 640 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 641 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 642 DOI 10.17487/RFC5289, August 2008, 643 . 645 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 646 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 647 January 2012, . 649 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 650 Langley, A., and M. Ray, "Transport Layer Security (TLS) 651 Session Hash and Extended Master Secret Extension", 652 RFC 7627, DOI 10.17487/RFC7627, September 2015, 653 . 655 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 656 Ephemeral Parameters for Transport Layer Security (TLS)", 657 RFC 7919, DOI 10.17487/RFC7919, August 2016, 658 . 660 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 661 "PKCS #1: RSA Cryptography Specifications Version 2.2", 662 RFC 8017, DOI 10.17487/RFC8017, November 2016, 663 . 665 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 666 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 667 May 2017, . 669 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 670 Curve Cryptography (ECC) Cipher Suites for Transport Layer 671 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 672 DOI 10.17487/RFC8422, August 2018, 673 . 675 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 676 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 677 . 679 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 680 Algorithm (CNSA) Suite Certificate and Certificate 681 Revocation List (CRL) Profile", RFC 8603, 682 DOI 10.17487/RFC8603, May 2019, 683 . 685 [SHS] National Institute of Standards and Technology, "Secure 686 Hash Standard (SHS)", NIST Federal Information Processing 687 Standard 180-4, August 2015, 688 . 691 10.2. Informative References 693 [SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain 694 Parameters", February 2010, 695 . 697 [SP80059] National Institute of Standards and Technology, "Guideline 698 for Identifying an Information System as a National 699 Security System", Special Publication 800 59, August 2003, 700 . 703 Author's Address 705 Dorothy Cooley 706 National Security Agency 708 Email: decoole@nsa.gov