idnits 2.17.1 draft-cooley-cnsa-dtls-tls-profile-00.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 (August 14, 2019) is 1717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6066' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC6961' is defined on line 542, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 6961 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 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 August 14, 2019 5 Expires: February 15, 2020 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-00 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 15, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 6 70 5.4. Certificates . . . . . . . . . . . . . . . . . . . . . . 7 71 6. (D)TLS 1.2 Requirements . . . . . . . . . . . . . . . . . . . 7 72 6.1. The signature_algorithms Extension . . . . . . . . . . . 7 73 6.2. The CertificateRequest Message . . . . . . . . . . . . . 8 74 6.3. The CertificateVerify Message . . . . . . . . . . . . . . 8 75 6.4. The Signature in the ServerKeyExchange Message . . . . . 8 76 6.5. Certificate Status . . . . . . . . . . . . . . . . . . . 8 77 7. (D)TLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7.1. The "signature_algorithms" and 79 "signature_algorithms_cert" Extensions . . . . . . . . . 9 80 7.2. The "early_data" Extension . . . . . . . . . . . . . . . 9 81 7.3. Resumption . . . . . . . . . . . . . . . . . . . . . . . 9 82 7.4. Certificate Status . . . . . . . . . . . . . . . . . . . 10 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 10.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 This document specifies a profile of TLS version 1.2 [RFC5246] and 93 TLS version 1.3 [RFC8446], as well as DTLS version 1.2 [RFC6347] and 94 DTLS version 1.3 [ID.dtls13] for use by applications that support the 95 National Security Agency's (NSA) Commercial National Security 96 Algorithm (CNSA) Suite [CNSA]. The profile applies to the 97 capabilities, configuration, and operation of all components of US 98 National Security Systems [SP80059]. It is also appropriate for all 99 other US Government systems that process high-value information. It 100 is made publicly available for use by developers and operators of 101 these and any other system deployments. 103 This document does not define any new cipher suites; instead, it 104 defines a CNSA compliant profile of TLS and DTLS, and the cipher 105 suites defined in [RFC5288] and [RFC5289]. This profile uses only 106 algorithms in the CNSA Suite. 108 The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as 109 well as the DTLS 1.2 and 1.3 protocol specifications: [RFC5246], 110 [RFC6347], [RFC8446], and [ID.dtls13]. All MUST-level requirements 111 from the protocol documents apply throughout this profile; they are 112 generally not repeated. This profile contains changes that elevate 113 some SHOULD-level options to MUST-level; this profile also contains 114 changes that elevate some MAY-level options to SHOULD-level or MUST- 115 level. All options that are not mentioned in this profile remain at 116 their original requirement level. 118 2. The Commercial National Security Algorithm Suite 120 The National Security Agency (NSA) profiles commercial cryptographic 121 algorithms and protocols as part of its mission to support secure, 122 interoperable communications for US Government National Security 123 Systems. To this end, it publishes guidance both to assist with the 124 US Government transition to new algorithms, and to provide vendors - 125 and the Internet community in general - with information concerning 126 their proper use and configuration. 128 Recently, cryptographic transition plans have become overshadowed by 129 the prospect of the development of a cryptographically-relevant 130 quantum computer. NSA has established the CNSA Suite to provide 131 vendors and IT users near-term flexibility in meeting their 132 Information Assurance (IA) interoperability requirements. The 133 purpose behind this flexibility is to avoid having vendors and 134 customers make two major transitions in a relatively short timeframe, 135 as we anticipate a need to shift to quantum-resistant cryptography in 136 the near future. 138 NSA is authoring a set of RFCs, including this one, to provide 139 updated guidance concerning the use of certain commonly available 140 commercial algorithms in IETF protocols. These RFCs can be used in 141 conjunction with other RFCs and cryptographic guidance (e.g., NIST 142 Special Publications) to properly protect Internet traffic and data- 143 at-rest for US Government National Security Systems. 145 3. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 "ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital 154 Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), 155 respectively. ECDSA and ECDH are used with the NIST P-384 curve 156 (which is based on a 384-bit prime modulus) and the SHA-384 hash 157 function. Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman 158 (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH 159 are used with a 3072-bit or 4096-bit modulus. When RSA is used for 160 digital signature, it is used with the SHA-384 hash function. 162 Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS 163 versions 1.2 and 1.3 collectively as (D)TLS. 165 4. CNSA Suite 167 [CNSA] approves the use of both finite field and elliptic curve 168 versions of the DH key agreement algorithm, as well as RSA-based key 169 establishment. [CNSA] also approves certain versions of the RSA and 170 elliptic curve digital signature algorithms. The approved encryption 171 techniques include the Advanced Encryption Standard (AES) used with a 172 256-bit key in an Authenticated Encryption with Associated Data 173 (AEAD) mode. 175 In particular, CNSA includes the following: 177 Encryption: 179 AES [AES] (with key size 256 bits), operating in Galois/Counter 180 Mode (GCM) [GCM] 182 Digital Signature: 184 ECDSA [DSS] (using the NIST P-384 elliptic curve) 186 RSA [DSS] (with a modulus of 3072 bits or 4096 bits) 188 Key Establishment (includes key agreement and key transport): 190 ECDH [PWKE-A] (using the NIST P-384 elliptic curve) 192 DH [PWKE-A] (with a prime modulus of 3072 or 4096 bits) 193 RSA [PWKE-B] (with a modulus of 3072 or 4096 bits) 195 [CNSA] also approves the use of SHA-384 [SHS] for the hash algorithm 196 for mask generation, signature generation, Pseudo Random Function 197 (PRF) in TLS 1.2 and HMAC-based key derivation function (HKDF) in TLS 198 1.3. 200 4.1. CNSA (D)TLS Key Establishment Algorithms 202 The following combination of algorithms and key sizes are used in 203 CNSA (D)TLS: 205 AES with 256-bit key, operating in GCM mode 207 ECDH [PWKE-A] using the Ephemeral Unified Model Scheme with 208 cofactor set to 1 (see Section 6.1.2.2 in [PWKE-A]) 210 TLS PRF/HKDF with SHA-384 [SHS] 212 Or 214 AES with 256-bit key, operating in GCM mode 216 RSA key transport using 3072-bit or 4096-bit modulus 217 [PWKE-B][RFC8017] 219 TLS PRF/HKDF with SHA-384 [SHS] 221 Or 223 AES with 256-bit key, operating in GCM mode 225 DH using dhEphem with domain parameters specified below (see 226 Section 6.1.2.1 in [PWKE-A]) 228 TLS PRF/HKDF with SHA-384 [SHS] 230 The specific CNSA compliant cipher suites are listed in Section 5. 232 4.2. CNSA TLS Authentication 234 For server and/or client authentication, CNSA (D)TLS MUST generate 235 and verify either ECDSA signatures or RSA signatures. 237 In all cases, the client MUST authenticate the server. The server 238 MAY also authenticate the client, as needed by the specific 239 application. 241 5. CNSA Compliance and Interoperability Requirements 243 CNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA 244 compliant system. CNSA (D)TLS servers and clients MUST implement and 245 use either (D)TLS version 1.2 [RFC5246][RFC6347] or (D)TLS version 246 1.3 [RFC8446][ID.dtls13]. 248 5.1. Acceptable ECC Curves 250 The elliptic curves used in the CNSA Suite appear in the literature 251 under two different names [DSS] [SECG]. For the sake of clarity, 252 both names are listed below: 254 Curve NIST name SECG name 255 -------------------------------- 256 P-384 nistp384 secp384r1 258 [RFC8422] defines a variety of elliptic curves. CNSA (D)TLS 259 connections MUST use secp384r1(24) (also called nistp384) and the 260 uncompressed(0) form MUST be supported, as required by [RFC8422] and 261 [RFC8446]. 263 Key pairs MUST be generated following Section 5.6.1.2 of [PWKE-A]. 265 5.2. Acceptable RSA Schemes, Parameters and Checks 267 [CNSA] specifies a minimum modulus size of 3072 bits; however, only 268 two modulus sizes (3072 bits and 4096 bits) are supported by this 269 profile. 271 For authentication, RSASSA-PKCS1-v1.5 [RFC8017] MUST be supported, 272 and RSASSA-PSS [DSS] SHOULD be supported. 274 For key transport, RSAES-PKCS1-v1.5 [RFC8017] MUST be supported. 276 RSA exponent e MUST satisfy 2^16. 473 [CNSA] Committee for National Security Systems, "Use of Public 474 Standards for Secure Information Sharing", CNSSP 15, 475 October 2016, 476 . 478 [DSS] National Institute of Standards and Technology, "Digital 479 Signature Standard (DSS)", NIST Federal Information 480 Processing Standard 186-4, July 2013, 481 . 484 [GCM] National Institute of Standards and Technology, 485 "Recommendation for Block Cipher Modes of Operation: 486 Galois/Counter Mode (GCM) and GMAC", NIST Special 487 Publication 800-38D, November 2007, 488 . 491 [ID.dtls13] 492 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 493 Datagram Transport Layer Security (DTLS) Protocol Version 494 1.3", March 2019, 495 . 497 Work in progress. 499 [PWKE-A] National Institute of Standards and Technology, 500 "Recommendation for Pair-Wise Key Establishment Schemes 501 Using Discrete Logarithm Cryptography", NIST Special 502 Publication 800-56A, Revision 3, April 2018, 503 . 506 [PWKE-B] National Institute of Standards and Technology, 507 "Recommendation for Pair-Wise Key Establishment Schemes 508 Using Integer Factorization Cryptography", NIST Special 509 Publication 800-56B, Revision 2, March 2019, 510 . 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, 515 DOI 10.17487/RFC2119, March 1997, 516 . 518 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 519 (TLS) Protocol Version 1.2", RFC 5246, 520 DOI 10.17487/RFC5246, August 2008, 521 . 523 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 524 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 525 DOI 10.17487/RFC5288, August 2008, 526 . 528 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 529 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 530 DOI 10.17487/RFC5289, August 2008, 531 . 533 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 534 Extensions: Extension Definitions", RFC 6066, 535 DOI 10.17487/RFC6066, January 2011, 536 . 538 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 539 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 540 January 2012, . 542 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 543 Multiple Certificate Status Request Extension", RFC 6961, 544 DOI 10.17487/RFC6961, June 2013, 545 . 547 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 548 Ephemeral Parameters for Transport Layer Security (TLS)", 549 RFC 7919, DOI 10.17487/RFC7919, August 2016, 550 . 552 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 553 "PKCS #1: RSA Cryptography Specifications Version 2.2", 554 RFC 8017, DOI 10.17487/RFC8017, November 2016, 555 . 557 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 558 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 559 May 2017, . 561 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 562 Curve Cryptography (ECC) Cipher Suites for Transport Layer 563 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 564 DOI 10.17487/RFC8422, August 2018, 565 . 567 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 568 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 569 . 571 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 572 Algorithm (CNSA) Suite Certificate and Certificate 573 Revocation List (CRL) Profile", RFC 8603, 574 DOI 10.17487/RFC8603, May 2019, 575 . 577 [SHS] National Institute of Standards and Technology, "Secure 578 Hash Standard (SHS)", NIST Federal Information Processing 579 Standard 180-4, August 2015, 580 . 583 10.2. Informative References 585 [SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain 586 Parameters", February 2010, 587 . 589 [SP80059] National Institute of Standards and Technology, "Guideline 590 for Identifying an Information System as a National 591 Security System", Special Publication 800 59, August 2003, 592 . 595 Author's Address 597 Dorothy Cooley 598 National Security Agency 600 Email: decoole@nsa.gov