idnits 2.17.1 draft-cooley-cnsa-dtls-tls-profile-01.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 (December 12, 2019) is 1596 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 December 12, 2019 5 Expires: June 14, 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-01 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 June 14, 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 . . . . . . . . . . . . . 7 70 5.4. Certificates . . . . . . . . . . . . . . . . . . . . . . 7 71 6. (D)TLS 1.2 Requirements . . . . . . . . . . . . . . . . . . . 7 72 6.1. The signature_algorithms Extension . . . . . . . . . . . 8 73 6.2. The signature_algorithms_cert Extension . . . . . . . . . 8 74 6.3. The CertificateRequest Message . . . . . . . . . . . . . 9 75 6.4. The CertificateVerify Message . . . . . . . . . . . . . . 9 76 6.5. The Signature in the ServerKeyExchange Message . . . . . 9 77 6.6. Certificate Status . . . . . . . . . . . . . . . . . . . 9 78 7. (D)TLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7.1. The "signature_algorithms" and 80 "signature_algorithms_cert" Extensions . . . . . . . . . 10 81 7.2. The "early_data" Extension . . . . . . . . . . . . . . . 10 82 7.3. Resumption . . . . . . . . . . . . . . . . . . . . . . . 11 83 7.4. Certificate Status . . . . . . . . . . . . . . . . . . . 11 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 10.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 This document specifies a profile of TLS version 1.2 [RFC5246] and 94 TLS version 1.3 [RFC8446], as well as DTLS version 1.2 [RFC6347] and 95 DTLS version 1.3 [ID.dtls13] for use by applications that support the 96 National Security Agency's (NSA) Commercial National Security 97 Algorithm (CNSA) Suite [CNSA]. The profile applies to the 98 capabilities, configuration, and operation of all components of US 99 National Security Systems [SP80059]. It is also appropriate for all 100 other US Government systems that process high-value information. It 101 is made publicly available for use by developers and operators of 102 these and any other system deployments. 104 This document does not define any new cipher suites; instead, it 105 defines a CNSA compliant profile of TLS and DTLS, and the cipher 106 suites defined in [RFC5288] and [RFC5289]. This profile uses only 107 algorithms in the CNSA Suite. 109 The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as 110 well as the DTLS 1.2 and 1.3 protocol specifications: [RFC5246], 111 [RFC6347], [RFC8446], and [ID.dtls13]. All MUST-level requirements 112 from the protocol documents apply throughout this profile; they are 113 generally not repeated. This profile contains changes that elevate 114 some SHOULD-level options to MUST-level; this profile also contains 115 changes that elevate some MAY-level options to SHOULD-level or MUST- 116 level. All options that are not mentioned in this profile remain at 117 their original requirement level. 119 2. The Commercial National Security Algorithm Suite 121 The National Security Agency (NSA) profiles commercial cryptographic 122 algorithms and protocols as part of its mission to support secure, 123 interoperable communications for US Government National Security 124 Systems. To this end, it publishes guidance both to assist with the 125 US Government transition to new algorithms, and to provide vendors - 126 and the Internet community in general - with information concerning 127 their proper use and configuration. 129 Recently, cryptographic transition plans have become overshadowed by 130 the prospect of the development of a cryptographically-relevant 131 quantum computer. NSA has established the CNSA Suite to provide 132 vendors and IT users near-term flexibility in meeting their 133 Information Assurance (IA) interoperability requirements. The 134 purpose behind this flexibility is to avoid having vendors and 135 customers make two major transitions in a relatively short timeframe, 136 as we anticipate a need to shift to quantum-resistant cryptography in 137 the near future. 139 NSA is authoring a set of RFCs, including this one, to provide 140 updated guidance concerning the use of certain commonly available 141 commercial algorithms in IETF protocols. These RFCs can be used in 142 conjunction with other RFCs and cryptographic guidance (e.g., NIST 143 Special Publications) to properly protect Internet traffic and data- 144 at-rest for US Government National Security Systems. 146 3. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 "ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital 155 Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), 156 respectively. ECDSA and ECDH are used with the NIST P-384 curve 157 (which is based on a 384-bit prime modulus) and the SHA-384 hash 158 function. Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman 159 (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH 160 are used with a 3072-bit or 4096-bit modulus. When RSA is used for 161 digital signature, it is used with the SHA-384 hash function. 163 Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS 164 versions 1.2 and 1.3 collectively as (D)TLS. 166 4. CNSA Suite 168 [CNSA] approves the use of both finite field and elliptic curve 169 versions of the DH key agreement algorithm, as well as RSA-based key 170 establishment. [CNSA] also approves certain versions of the RSA and 171 elliptic curve digital signature algorithms. The approved encryption 172 techniques include the Advanced Encryption Standard (AES) used with a 173 256-bit key in an Authenticated Encryption with Associated Data 174 (AEAD) mode. 176 In particular, CNSA includes the following: 178 Encryption: 180 AES [AES] (with key size 256 bits), operating in Galois/Counter 181 Mode (GCM) [GCM] 183 Digital Signature: 185 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 (see 228 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 5. CNSA Compliance and Interoperability Requirements 245 CNSA (D)TLS MUST NOT use TLS versions prior to (D)TLS 1.2 in a CNSA 246 compliant system. CNSA (D)TLS servers and clients MUST implement and 247 use either (D)TLS version 1.2 [RFC5246][RFC6347] or (D)TLS version 248 1.3 [RFC8446][ID.dtls13]. 250 5.1. Acceptable ECC Curves 252 The elliptic curves used in the CNSA Suite appear in the literature 253 under two different names [DSS] [SECG]. For the sake of clarity, 254 both names are listed below: 256 Curve NIST name SECG name 257 -------------------------------- 258 P-384 nistp384 secp384r1 260 [RFC8422] defines a variety of elliptic curves. CNSA (D)TLS 261 connections MUST use secp384r1(24) (also called nistp384) and the 262 uncompressed(0) form MUST be supported, as required by [RFC8422] and 263 [RFC8446]. 265 Key pairs MUST be generated following Section 5.6.1.2 of [PWKE-A]. 267 5.2. Acceptable RSA Schemes, Parameters and Checks 269 [CNSA] specifies a minimum modulus size of 3072 bits; however, only 270 two modulus sizes (3072 bits and 4096 bits) are supported by this 271 profile. 273 For authentication, RSASSA-PKCS1-v1.5 [RFC8017] MUST be supported, 274 and RSASSA-PSS [DSS] SHOULD be supported. 276 For key transport, RSAES-PKCS1-v1.5 [RFC8017] MUST be supported. 278 RSA exponent e MUST satisfy 2^16. 525 [CNSA] Committee for National Security Systems, "Use of Public 526 Standards for Secure Information Sharing", CNSSP 15, 527 October 2016, 528 . 530 [DSS] National Institute of Standards and Technology, "Digital 531 Signature Standard (DSS)", NIST Federal Information 532 Processing Standard 186-4, July 2013, 533 . 536 [GCM] National Institute of Standards and Technology, 537 "Recommendation for Block Cipher Modes of Operation: 538 Galois/Counter Mode (GCM) and GMAC", NIST Special 539 Publication 800-38D, November 2007, 540 . 543 [ID.dtls13] 544 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 545 Datagram Transport Layer Security (DTLS) Protocol Version 546 1.3", March 2019, 547 . 549 Work in progress. 551 [PWKE-A] National Institute of Standards and Technology, 552 "Recommendation for Pair-Wise Key Establishment Schemes 553 Using Discrete Logarithm Cryptography", NIST Special 554 Publication 800-56A, Revision 3, April 2018, 555 . 558 [PWKE-B] National Institute of Standards and Technology, 559 "Recommendation for Pair-Wise Key Establishment Schemes 560 Using Integer Factorization Cryptography", NIST Special 561 Publication 800-56B, Revision 2, March 2019, 562 . 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, 567 DOI 10.17487/RFC2119, March 1997, 568 . 570 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 571 (TLS) Protocol Version 1.2", RFC 5246, 572 DOI 10.17487/RFC5246, August 2008, 573 . 575 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 576 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 577 DOI 10.17487/RFC5288, August 2008, 578 . 580 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 581 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 582 DOI 10.17487/RFC5289, August 2008, 583 . 585 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 586 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 587 January 2012, . 589 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 590 Ephemeral Parameters for Transport Layer Security (TLS)", 591 RFC 7919, DOI 10.17487/RFC7919, August 2016, 592 . 594 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 595 "PKCS #1: RSA Cryptography Specifications Version 2.2", 596 RFC 8017, DOI 10.17487/RFC8017, November 2016, 597 . 599 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 600 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 601 May 2017, . 603 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 604 Curve Cryptography (ECC) Cipher Suites for Transport Layer 605 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 606 DOI 10.17487/RFC8422, August 2018, 607 . 609 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 610 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 611 . 613 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 614 Algorithm (CNSA) Suite Certificate and Certificate 615 Revocation List (CRL) Profile", RFC 8603, 616 DOI 10.17487/RFC8603, May 2019, 617 . 619 [SHS] National Institute of Standards and Technology, "Secure 620 Hash Standard (SHS)", NIST Federal Information Processing 621 Standard 180-4, August 2015, 622 . 625 10.2. Informative References 627 [SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain 628 Parameters", February 2010, 629 . 631 [SP80059] National Institute of Standards and Technology, "Guideline 632 for Identifying an Information System as a National 633 Security System", Special Publication 800 59, August 2003, 634 . 637 Author's Address 639 Dorothy Cooley 640 National Security Agency 642 Email: decoole@nsa.gov