idnits 2.17.1 draft-smyshlyaev-tls13-gost-suites-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 (October 29, 2019) is 1641 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Smyshlyaev, Ed. 3 Internet-Draft E. Alekseev 4 Intended status: Informational E. Smyshlyaeva 5 Expires: May 1, 2020 A. Babueva 6 CryptoPro 7 October 29, 2019 9 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 10 1.3 11 draft-smyshlyaev-tls13-gost-suites-00 13 Abstract 15 This document specifies a set of cipher suites for the Transport 16 Layer Security (TLS) protocol Version 1.3 to support the Russian 17 cryptographic standard algorithms. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 1, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. Basic Terms and Definitions . . . . . . . . . . . . . . . . . 3 56 4. Cipher Suite Definition . . . . . . . . . . . . . . . . . . . 5 57 4.1. Payload Protection . . . . . . . . . . . . . . . . . . . 5 58 4.1.1. AEAD Algorithm . . . . . . . . . . . . . . . . . . . 6 59 4.1.1.1. Block Cipher . . . . . . . . . . . . . . . . . . 7 60 4.1.1.2. TLSTREE . . . . . . . . . . . . . . . . . . . . . 8 61 4.1.1.3. SNMAX parameter . . . . . . . . . . . . . . . . . 9 62 4.2. HASH algorithm . . . . . . . . . . . . . . . . . . . . . 9 63 5. Signature Scheme Definition . . . . . . . . . . . . . . . . . 10 64 6. Key Exchange and Authentication . . . . . . . . . . . . . . . 12 65 6.1. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1.1. ECDHE Shared Secret Calculation . . . . . . . . . . . 13 67 6.1.1.1. ECDHE Parameters . . . . . . . . . . . . . . . . 13 68 6.1.1.2. ECDHE Shared Secret Calculation on Client Side . 14 69 6.1.1.3. ECDHE Shared Secret Calculation on Server Side . 15 70 6.1.2. Values for the Supported Groups Registry . . . . . . 16 71 6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 17 72 6.3. Handshake Messages . . . . . . . . . . . . . . . . . . . 17 73 6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 18 74 6.3.2. CertificateRequest . . . . . . . . . . . . . . . . . 18 75 6.3.3. CertificateVerify . . . . . . . . . . . . . . . . . . 19 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 8. Historical considerations . . . . . . . . . . . . . . . . . . 21 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 81 10.2. Informative References . . . . . . . . . . . . . . . . . 23 82 Appendix A. Test Examples . . . . . . . . . . . . . . . . . . . 23 83 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 23 84 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 23 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 87 1. Introduction 89 This document specifies four new cipher suites for the Transport 90 Layer Security (TLS) Protocol Version 1.3 [RFC8446] to support the 91 set of Russian cryptographic standard algorithms called GOST 92 algorithms (see Section 4). These cipher suites use the hash 93 algorithm GOST R 34.11-2012 [GOST3411-2012] (the English version can 94 be found in [RFC6986]), the AEAD algorithm MGM [DraftMGM] and the 95 block ciphers GOST R 34.12-2015 [GOST3412-2015] (the English version 96 can be found in [RFC7801]). The GOST cipher suites have the 97 following values: 99 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {TBD1}; 100 TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {TBD2}; 101 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {TBD3}; 102 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {TBD4}. 104 These cipher suites have different key lifetime value (see 105 [RFC8645]), so they are divided into two types: the _S (strong) 106 cipher suites and the _L (light) cipher suites (see Section 4.1.1.3, 107 Section 4.1.1.2). 109 This document specifies seven new signature schemes (see Section 5) 110 to be used with GOST cipher suites. These signature schemes use the 111 signature algorithm GOST R 34.10-2012 [GOST3410-2012] (the English 112 version can be found in [RFC7091]) and have the following values: 114 gostr34102012_256a = {TBD5}; 116 gostr34102012_256b = {TBD6}; 118 gostr34102012_256c = {TBD7}; 120 gostr34102012_256d = {TBD8}; 122 gostr34102012_512a = {TBD9}; 124 gostr34102012_512b = {TBD10}; 126 gostr34102012_512c = {TBD11}. 128 Additionally this document specifies the key exchange and 129 authentication process in case of negotiating GOST cipher suites (see 130 Section 6). 132 2. Conventions Used in This Document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Basic Terms and Definitions 140 This document uses the following terms and definitions for the sets 141 and operations on the elements of these sets: 143 B_t the set of byte strings of length t, t >= 0, for t = 0 the 144 B_t set consists of a single empty string of zero length. If 145 A is an element of B_t, then A = (a_1, a_2, ... , a_t), where 146 a_1, a_2, ... , a_t are in {0, ... , 255}; 148 B* the set of all byte strings of a finite length (hereinafter 149 referred to as strings), including the empty string; 151 A[i..j] the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in B_{j-i+1} 152 where A = (a_1, ... , a_t) in B_t and 1<=i<=j<=t; 154 |A| the byte length of the byte string A; 156 A | C concatenation of strings A and C both belonging to B*, i.e., 157 a string in B_{|A|+|C|}, where the left substring in B_|A| is 158 equal to A, and the right substring in B_|C| is equal to C; 160 i & j bitwise AND of integers i and j; 162 STR_t the transformation that maps an integer i = 256^{t-1} * i_1 + 163 ... + 256 * i_{t-1} + i_t into the byte string STR_t(i) = 164 (i_1, ... , i_t) in B_t (the interpretation of the integer as 165 a byte string in big-endian format); 167 str_t the transformation that maps an integer i = 256^{t-1} * i_t + 168 ... + 256 * i_2 + i_1 into the byte string str_t(i) = (i_1, 169 ... , i_t) in B_t (the interpretation of the integer as a 170 byte string in little-endian format); 172 k the byte-length of the block cipher key; 174 n the byte-length of the block cipher block; 176 E_i elliptic curve indicated by client in "supported_group" 177 extension; 179 Q_c the public key stored in the client's certificate; 181 d_c the private key that corresponds to the Q_c key; 183 Q_s the public key stored in the server's certificate; 185 d_s the private key that corresponds to the Q_s key; 187 q_s subgroup order of group of points of the elliptic curve that 188 corresponds to Q_s; 190 P_s the point of order q_s that belongs to the same curve as Q_s; 192 4. Cipher Suite Definition 194 This document defines the following new values for the "Cipher 195 Suites" registry, that can be used in the ClientHello.cipher_suites 196 and ServerHello.cipher_suites fields for the particular cipher suite: 198 CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = TBD1; 199 CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = TBD2; 200 CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = TBD3; 201 CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = TBD4; 203 Each cipher suite defines the pair of the AEAD algorithm and the hash 204 algorithm. AEAD algorithm is used for the payload protection (see 205 Section 4.1 for more details) and hash algorithm is used for key 206 derivation and handshake message authentication. 208 4.1. Payload Protection 210 All of the cipher suites described in this document use the block 211 cipher in Authenticated Encryption with Associated Data (AEAD) mode 212 (see Section 4.1.1) to protect records. The TLSCiphertext structure 213 is specified in accordance with [RFC8446] as follows. 215 struct { 216 ContentType opaque_type = application_data; /* 23 */ 217 ProtocolVersion legacy_record_version = 0x0303; /*TLSv1.2*/ 218 uint16 length; 219 opaque encrypted_record[TLSCiphertext.length]; 220 } TLSCiphertext; 222 The encrypted_record field of TLSCiphertext is set to AEADEncrypted, 223 where AEADEncrypted is computed as follows: 225 AEADEncrypted = AEAD-Encrypt(sender_write_key, nonce, 226 additional_data, plaintext), 228 where 230 o AEAD-Encrypt function is defined in Section 4.1.1; 232 o the traffic key material that consists of the sender_write_key 233 (either the client_write_key or the server_write_key) and the 234 sender_write_IV (either the client_write_IV or the 235 server_write_IV) parameters is generated in accordance with 236 Section 7.3 of [RFC8446]; 238 o the nonce is derived from the sequence number and the 239 sender_write_iv (see Section 5.3 of [RFC8446]); 241 o the plaintext input to the AEAD algorithm is the encoded 242 TLSInnerPlaintext structure; 244 o the additional data input is the record header: 246 additional_data = TLSCiphertext.opaque_type || 247 TLSCiphertext.legacy_record_version || 248 TLSCiphertext.length; 250 In order to decrypt and verify, the cipher takes as input the key, 251 nonce, additional data and the AEADEncrypted value. The output is 252 either the plaintext or an error indicating that the decryption 253 failed. 255 plaintext of encrypted_record = AEAD-Decrypt(sender_write_key, 256 nonce, additional_data, AEADEncrypted) 258 where AEAD-Decrypt function is defined in Section 4.1.1. 260 4.1.1. AEAD Algorithm 262 The GOST cipher suites use the block cipher in MGM authenticated 263 encryption with associated data mode defined in [DraftMGM]. The base 264 block cipher is defined in Section 4.1.1.1. The size S of the 265 authentication field is n bytes. The IVlen parameter is n bytes. 267 The record key material is a key material that is generated from the 268 traffic key material and is used to protect a record with the certain 269 sequence number. All of the cipher suites described in this document 270 use TLSTREE algorithm to derive record key material 271 (Section 4.1.1.2). 273 For each record with sequence number seqnum AEAD-Encrypt and AEAD- 274 Decrypt functions are defined as follows. 276 +-------------------------------------------------------------------+ 277 | AEAD-Encrypt(K, nonce, A, P) | 278 |-------------------------------------------------------------------| 279 | Input: | 280 | - encryption key K in B_k, | 281 | - unique vector nonce in B_IVlen, | 282 | - additional authenticated data A in B_s, s >= 0, | 283 | - plaintext P in B_s, s >= 0. | 284 | Output: | 285 | - ciphertext C in B_{|P|}, | 286 | - authentication tag T T in B_S. | 287 |-------------------------------------------------------------------| 288 | 1. K^seqnum = TLSTREE(K, seqnum) | 289 | 2. MGMnonce = nonce[1..1] & 0x7f | nonce[2..IVlen] | 290 | 3. (MGMnonce, A, C, T) = MGM-Encrypt(K^seqnum, MGMnonce, A, P) | 291 | 4. Return C | T. | 292 +-------------------------------------------------------------------+ 294 +-------------------------------------------------------------------+ 295 | AEAD-Decrypt(K, nonce, A, C | T) | 296 |-------------------------------------------------------------------| 297 | Input: | 298 | - encryption key K in B_k, | 299 | - unique vector nonce in B_IVlen, | 300 | - additional authenticated data A in B_s, s >= 0, | 301 | - ciphertext C in B_s, s >= 0 | 302 | - authentication tag T in B_S. | 303 | Output: | 304 | - plaintext P in B_{|C|} or FAIL. | 305 |-------------------------------------------------------------------| 306 | 1. K^seqnum = TLSTREE(K, seqnum) | 307 | 2. MGMnonce = nonce[1..1] & 0x7f | nonce[2..IVlen] | 308 | 3. res' = MGM-Decrypt(K^seqnum, MGMnonce, A, C, T) | 309 | 4. IF res' = FAIL then return FAIL; else return P. | 310 +-------------------------------------------------------------------+ 312 MGM-Encrypt and MGM-Decrypt functions are defined in [DraftMGM], 313 TLSTREE function is defined in Section 4.1.1.2. The maximum value of 314 the sequence number seqnum during one TLS 1.3 connection is defined 315 in Section 4.1.1.3. 317 4.1.1.1. Block Cipher 319 The cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and 320 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik 321 [RFC7801] as a base block cipher for the AEAD algorithm. The block 322 length n is 16 bytes and the key length k is 32 bytes. 324 The cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and 325 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST uses Magma [GOST3412-2015] 326 as a base block cipher for the AEAD algorithm. The block length n is 327 8 bytes and the key length k is 32 bytes. 329 4.1.1.2. TLSTREE 331 The GOST cipher suites use the TLSTREE function for the external re- 332 keying approach (see [RFC8645]). The TLSTREE function is defined as 333 follows: 335 TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8(i & C_1)), 336 STR_8(i & C_2)), STR_8(i & C_3)), 338 where 340 o K_root in B_32; 342 o i in {0, 1, ... , 2^64 - 1}; 344 o KDF_j(K, D), j = 1, 2, 3, K in B_32, D in B_8, is the key 345 derivation function based on the KDF_GOSTR3411_2012_256 function 346 defined in [RFC7836]: 348 KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D); 349 KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D); 350 KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D). 352 o C_1, C_2, C_3 are constants defined by the particular cipher 353 suite: 355 +------------------------------------------+----------------------+ 356 | CipherSuites | C_1, C_2, C_3 | 357 +------------------------------------------+----------------------+ 358 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L |C_1=0xf800000000000000| 359 | |C_2=0xfffffff000000000| 360 | |C_3=0xffffffffffffe000| 361 +------------------------------------------+----------------------+ 362 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L |C_1=0xffe0000000000000| 363 | |C_2=0xffffffffc0000000| 364 | |C_3=0xffffffffffffff80| 365 +------------------------------------------+----------------------+ 366 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S |C_1=0xffffffffe0000000| 367 | |C_2=0xffffffffffff0000| 368 | |C_3=0xfffffffffffffff8| 369 +------------------------------------------+----------------------+ 370 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S |C_1=0xfffffffffc000000| 371 | |C_2=0xffffffffffffe000| 372 | |C_3=0xffffffffffffffff| 373 +------------------------------------------+----------------------+ 374 Table 1 376 4.1.1.3. SNMAX parameter 378 The SNMAX parameter defines the maximal value of the sequence number 379 seqnum during one TLS 1.3 connection and is defined as follows: 381 +------------------------------------------+--------------------+ 382 | CipherSuites | SNMAX | 383 +------------------------------------------+--------------------+ 384 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L | SNMAX = 2^64 - 1 | 385 +------------------------------------------+--------------------+ 386 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L | SNMAX = 2^64 - 1 | 387 +------------------------------------------+--------------------+ 388 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S | SNMAX = 2^42 - 1 | 389 +------------------------------------------+--------------------+ 390 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | SNMAX = 2^39 - 1 | 391 +------------------------------------------+--------------------+ 392 Table 2 394 4.2. HASH algorithm 396 The function HASH for all the cipher suites defined in this document 397 is the GOST R 34.11-2012 [RFC6986] hash algorithm with 32-byte 398 (256-bit) hash code. 400 The function HASH is used for key derivation process (see Section 7.1 401 of [RFC8446]), Finished message calculation, Transcript-Hash 402 function, PSK binder value calculation, derivation of record key 403 material (see Section 4.1.1.2) and other purposes during key exchange 404 process. 406 5. Signature Scheme Definition 408 The signature scheme values are used to indicate to the server/client 409 which signature algorithms and curves can be used in digital 410 signatures and are defined by the SignatureSchemeList structure (see 411 Section 4.2.3 of [RFC8446]) as follows: 413 struct { 414 SignatureScheme supported_signature_algorithms<2..2^16-2>; 415 } SignatureSchemeList; 417 This document defines new values for the "SignatureAlgorithm" 418 registry that can be used in the 419 SignatureSchemeList.supported_signature_algorithms field for the 420 particular signature scheme: 422 enum { 423 gostr34102012_256a(TBD5), 424 gostr34102012_256b(TBD6), 425 gostr34102012_256c(TBD7), 426 gostr34102012_256d(TBD8), 427 gostr34102012_512a(TBD9), 428 gostr34102012_512b(TBD10), 429 gostr34102012_512c(TBD11) 430 } SignatureScheme; 432 where the values correspond to the following signature algorithms and 433 curves: 435 +------------------+--------------------------------------+--------+ 436 | SignatureScheme | Signature Algorithm | Refe- | 437 | Value | | rences | 438 +------------------+--------------------------------------+--------+ 439 |gostr34102012_256a|GOST R 34.10-2012 + 32-byte key length|RFC 7091| 440 +------------------+--------------------------------------+--------+ 441 |gostr34102012_256b|GOST R 34.10-2012 + 32-byte key length|RFC 7091| 442 +------------------+--------------------------------------+--------+ 443 |gostr34102012_256c|GOST R 34.10-2012 + 32-byte key length|RFC 7091| 444 +------------------+--------------------------------------+--------+ 445 |gostr34102012_256d|GOST R 34.10-2012 + 32-byte key length|RFC 7091| 446 +------------------+--------------------------------------+--------+ 447 |gostr34102012_512a|GOST R 34.10-2012 + 64-byte key length|RFC 7091| 448 +------------------+--------------------------------------+--------+ 449 |gostr34102012_512b|GOST R 34.10-2012 + 64-byte key length|RFC 7091| 450 +------------------+--------------------------------------+--------+ 451 |gostr34102012_512c|GOST R 34.10-2012 + 64-byte key length|RFC 7091| 452 +------------------+--------------------------------------+--------+ 453 Table 3 455 +------------------+--------------------------------------+--------+ 456 | SignatureScheme | Curve Identifier Value | Refe- | 457 | Value | | rences | 458 +------------------+--------------------------------------+--------+ 459 |gostr34102012_256a| id-tc26-gost-3410-2012-256-paramSetA |RFC 7836| 460 +------------------+--------------------------------------+--------+ 461 |gostr34102012_256b|id-GostR3410-2001-CryptoPro-A-ParamSet|RFC 4357| 462 +------------------+--------------------------------------+--------+ 463 |gostr34102012_256c|id-GostR3410-2001-CryptoPro-B-ParamSet|RFC 4357| 464 +------------------+--------------------------------------+--------+ 465 |gostr34102012_256d|id-GostR3410-2001-CryptoPro-C-ParamSet|RFC 4357| 466 +------------------+--------------------------------------+--------+ 467 |gostr34102012_512a| id-tc26-gost-3410-12-512-paramSetA |RFC 7836| 468 +------------------+--------------------------------------+--------+ 469 |gostr34102012_512b| id-tc26-gost-3410-12-512-paramSetB |RFC 7836| 470 +------------------+--------------------------------------+--------+ 471 |gostr34102012_512c| id-tc26-gost-3410-2012-512-paramSetC |RFC 7836| 472 +------------------+--------------------------------------+--------+ 473 Table 4 475 This document defines the SIGN function which is used for computing 476 signature value in CertificateVerify message (see Section 6.3.3) as 477 follows. 479 +-----------------------------------------------------+ 480 | SIGN(M, d_sign) | 481 |-----------------------------------------------------| 482 | Input: | 483 | - the byte string M in B*; | 484 | - the sign key d_sign: 0 <= d_sign <= q. | 485 | Output: | 486 | - signature value sgn in B_{2*l}. | 487 |-----------------------------------------------------| 488 | 1. (r, s) = SIGNGOST(M, d_sign) | 489 | 2. Return str_l(r) | str_l(s) | 490 |-----------------------------------------------------+ 492 where 494 o q is the subgroup order of group of points of the elliptic curve; 496 o l is defined as follows: 498 * l = 32 for gostr34102012_256a, gostr34102012_256b, 499 gostr34102012_256c and gostr34102012_256d values of the 500 SignatureScheme field; 502 * l = 64 for gostr34102012_512a, gostr34102012_512b and 503 gostr34102012_512c values of the SignatureScheme field; 505 o SIGNGOST(M, d_sign) is the GOST R 34.10-2012 [RFC7091] signature 506 algorithm. 508 The signature value sgn is the concatenation of two strings that are 509 byte representations of r and s values in the little-endian format. 511 According to [RFC7091] the GOST R 34.10-2012 signature algorithm with 512 32-byte (256-bit) or 64-byte (512-bit) key length use the GOST R 513 34.11-2012 [RFC6986] hash algorithm with 32-byte (256-bit) or 64-byte 514 (512-bit) hash code respectively (the hash algorithm is intrinsic to 515 the signature algorithm). 517 6. Key Exchange and Authentication 519 Key exchange and authentication process in case of using GOST cipher 520 suites is defined in [RFC8446] and Section 6.1, Section 6.2. 521 Additionally the proposed cipher suites specify some Handshake 522 messages (see Section 6.3). 524 6.1. Key Exchange 526 TLS 1.3 supports three basic key exchange modes in accordance with 527 [RFC8446]: 529 1. (EC)DHE 531 2. PSK-only 533 3. PSK with (EC)DHE 535 All of the cipher suites described in this document use Diffie- 536 Hellman over elliptic curves in (EC)DHE and PSK with (EC)DHE key 537 exchange modes. Diffie-Hellman over finite fields SHOULD NOT be 538 used. This document defines the process of ECDHE shared secret 539 calculation (see Section 6.1.1) and specifies the elliptic curves 540 that can be used during this process (see Section 6.1.2). 542 In accordance with [RFC8446] PSKs can be divided into two types: 544 o internal PSKs which can be established during the previous 545 connection; 547 o external PSKs which can be established out of band. 549 This document defines that PSK-only key exchange mode SHOULD be used 550 only with the internal PSKs. External PSKs SHOULD be used together 551 with certificates in PSK with (EC)DHE mode only. 553 6.1.1. ECDHE Shared Secret Calculation 555 6.1.1.1. ECDHE Parameters 557 ECDHE parameters for both clients and servers are encoded in the 558 opaque key_exchange field of a KeyShareEntry in a KeyShare structure. 560 For GOST cipher suites the contents are the serialized value of the 561 following struct: 563 struct { 564 opaque X[coordinate_length]; 565 opaque Y[coordinate_length]; 566 } PlainPointRepresentation; 567 X and Y, respectively, contain the binary representations of the x 568 and y values of point Q (Q = (x, y)) in the little-endian format and 569 are specified as follows: 571 X = str_{coordinate_length}(x); 573 Y = str_{coordinate_length}(y). 575 The coordinate_length value is defined in Table 5. 577 6.1.1.2. ECDHE Shared Secret Calculation on Client Side 579 The client calculates ECDHE shared secret value in accordance with 580 the following steps: 582 1. Chooses from all supported curves E_1, ..., E_R the set of curves 583 E_{i_1}, ..., E_{i_r}, 1 <= i_1 <= i_r <= R, where 585 o r >= 1 in the case of first message; 587 o r = 1 in the case of responding to HelloRetryRequest message, 588 E_{i_1} SHOULD correspond to the curve indicated in the key_share 589 extension in the HelloRetryRequest message. 591 2. Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ..., 592 (d_C^{i_r}, Q_C^{i_r}) corresponding to E_{i_1}, ..., E_{i_r} curves, 593 where for each i in {i_1, ..., i_r}: 595 o d_C^i is chosen from {1, ..., q_i - 1} at random; 597 o Q_C^i = d_C^i * P_i. 599 3. Sends ClientHello message specified in accordance with 600 Section 4.1.2 of [RFC8446] and Section 6.3.1, which contains: 602 o key_share extension with public ephemeral keys Q_C^{i_1}, ..., 603 Q_C^{i_r} specified in accordance with Section 4.2.8 of [RFC8446]; 605 o supported_group extension with supported curves E_1, ..., E_R 606 specified in accordance with Section 4.2.7 of [RFC8446]. 608 4. In case of receiving HelloRetryRequest message client should 609 return to step 1 and correct parameters according to Section 4.1.2 of 610 [RFC8446]. In case of receiving ServerHello message client proceeds 611 to the next step. In other cases client MUST terminate the 612 connection with "unexpected_message" alert. 614 5. Extracts curve E_res and ephemeral key Q_S^res, res in {1, ..., 615 R}, from ServerHello message and checks whether the Q_res belongs to 616 E_res. If this check fails, the client MUST abort the handshake with 617 "handshake_failure" alert. 619 6. Generates Q^ECDHE: 621 Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) * Q_S^res. 623 7. Client MUST check whether the computed shared secret Q^ECDHE is 624 not equal to zero point. If this check fails, the client MUST abort 625 the handshake with "handshake_failure" alert. 627 8. Shared secret value ECDHE is the byte representation of the 628 coordinate X^ECDHE of point Q^ECDHE in the little-endian format: 630 ECDHE = str_{coordinate_length}(X^ECDHE), 632 where coordinate_length is defined in Table 5. 634 6.1.1.3. ECDHE Shared Secret Calculation on Server Side 636 Upon receiving the ClientHello message, the server calculates ECDHE 637 shared secret value in accordance with the following steps: 639 1. Chooses the curve E_res, res in {1, ..., R} from the list of 640 curves E_1, ..., E_R indicated in supported_group extension in 641 ClientHello message and the corresponding public ephemeral key value 642 Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r}, 1 <= i_1 <= i_r <= 643 R, indicated in key_share extension. If no corresponding public 644 ephemeral key value is found (res in {1, ..., R}\{i_1, ..., i_r}), 645 server MAY send HelloRetryRequest message with key_share extension 646 indicated E_res and wait for the next ClientHello message. 648 2. Checks whether Q_res belongs to E_res. If this check fails, the 649 server MUST abort the handshake with "handshake_failure" alert. 651 3. Generates ephemeral key pair (d_S^res, Q_S^res) corresponding to 652 E_res: 654 o d_S^res is chosen from {1, ..., q_res - 1} at random; 656 o Q_S^res = d_S^res * P_res. 658 4. Sends ServerHello message specified in accordance with 659 Section 4.1.3 of [RFC8446] and Section 6.3.1 with key_share extension 660 indicated public ephemeral key value Q_S^res corresponding to E_res. 662 5. Generates Q^ECDHE: 664 Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res. 666 6. Server MUST check whether the computed shared secret Q^ECDHE is 667 not equal to zero point. If this check fails, the server MUST abort 668 the handshake with "handshake_failure" alert. 670 7. Shared secret value ECDHE is the byte representation of the 671 coordinate X^ECDHE of point Q^ECDHE in the little-endian format: 673 ECDHE = str_{coordinate_length}(X^ECDHE), 675 where coordinate_length is defined in Table 5. 677 6.1.2. Values for the Supported Groups Registry 679 The supported_groups extension indicates the set of elliptic curves 680 supported by the client and is defined in [RFC8446]. 682 This document defines the following values for the "Supported Groups" 683 registry: 685 enum { 686 GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25), 687 GC512A(0x26), GC512B(0x27), GC512C(0x28) 688 } NamedGroup; 690 Where the values correspond to the following curves and the following 691 values of coordinate_length parameter ("cl" column). 693 +-----------+--------------------------------------+----+---------+ 694 |Description| Curve Identifier Value | cl |Reference| 695 +-----------+--------------------------------------+----+---------+ 696 | GC256A | id-tc26-gost-3410-2012-256-paramSetA | 32 | RFC 7836| 697 +-----------+--------------------------------------+----+---------+ 698 | GC256B |id-GostR3410-2001-CryptoPro-A-ParamSet| 32 | RFC 4357| 699 +-----------+--------------------------------------+----+---------+ 700 | GC256C |id-GostR3410-2001-CryptoPro-B-ParamSet| 32 | RFC 4357| 701 +-----------+--------------------------------------+----+---------+ 702 | GC256D |id-GostR3410-2001-CryptoPro-C-ParamSet| 32 | RFC 4357| 703 +-----------+--------------------------------------+----+---------+ 704 | GC512A | id-tc26-gost-3410-12-512-paramSetA | 64 | RFC 7836| 705 +-----------+--------------------------------------+----+---------+ 706 | GC512B | id-tc26-gost-3410-12-512-paramSetB | 64 | RFC 7836| 707 +-----------+--------------------------------------+----+---------+ 708 | GC512C | id-tc26-gost-3410-2012-512-paramSetC | 64 | RFC 7836| 709 +-----------+--------------------------------------+----+---------+ 710 Table 5 712 These values are the same as in [DraftGostTLS12]. 714 6.2. Authentication 716 In accordance with [RFC8446] authentication can happen via signature 717 with certificate or via symmetric pre-shared key (PSK). The server 718 side of the channel is always authenticated; the client side is 719 optionally authenticated. 721 PSK-based authentication happens as a side effect of key exchange. 722 This document defines that external PSKs SHOULD be combined only with 723 the mutual autentication. 725 Certificate-based authentication happens via authentication messages. 726 This document defines the signature schemes that are used for 727 certificate-based authentication (see Section 5) and specifies some 728 autehtication messages (see Section 6.3.2, Section 6.3.3). 730 6.3. Handshake Messages 732 The proposed cipher suites specify the ClientHello, ServerHello, 733 CertificateRequest and CertificateVerify handshake messages, that are 734 described in further detail below. 736 6.3.1. Hello Messages 738 The ClientHello message is generated in accordance with the following 739 requirements. 741 o The ClientHello.cipher_suites field SHOULD contain cipher suites 742 with the values defined in Section 4. 744 o The ClientHello.extensions field MAY contain the 745 signature_algorithms and signature_algorithms_cert extensions. 746 The extension_data field of these extensions contains a 747 SignatureSchemeList value, where 748 SignatureSchemeList.supported_signature_algorithms field SHOULD 749 contain only the values defined in Section 5. 751 o The ClientHello.extensions field MAY contain the supported_group 752 extension. The extension_data field of this extension contains a 753 NamedGroupList value, where NamedGroupList.named_group_list field 754 SHOULD contain only the values defined in Section 6.1.2. 756 o The ClientHello.extensions field SHOULD NOT contain early_data 757 extension. 759 The ServerHello message is generated in accordance with the following 760 requirements. 762 o The ServerHello.cipher_suites field SHOULD contain cipher suites 763 with the values defined in Section 4. 765 6.3.2. CertificateRequest 767 This message is sent when requesting client authentication and is 768 specified in accordance with [RFC8446] as follows. 770 struct { 771 opaque certificate_request_context<0..2^8-1>; 772 Extension extensions<2..2^16-1>; 773 } CertificateRequest; 775 If the GOST cipher suite is negotiated, the CertificateRequest 776 message MUST meet the following requirements. 778 o The CertificateRequest.extensions field MUST contain the 779 signature_algorithms extension. The "extension_data" field of 780 this extension contains a SignatureSchemeList value, where 781 SignatureSchemeList.supported_signature_algorithms field SHOULD 782 contain only the values defined in Section 5. 784 o The CertificateRequest.extensions field MAY contain the 785 signature_algorithms_cert extension. The "extension_data" field 786 of this extension contains a SignatureSchemeList value, where 787 SignatureSchemeList.supported_signature_algorithms field SHOULD 788 contain only the values defined in Section 5. 790 6.3.3. CertificateVerify 792 This CertificateVerify message is used to provide explicit proof that 793 an endpoint possesses the private key corresponding to its 794 certificate and is specified in accordance with [RFC8446] as follows. 796 struct { 797 SignatureScheme algorithm; 798 opaque signature<0..2^16-1>; 799 } CertificateVerify; 801 If the GOST cipher suite is negotiated, the CertificateVerify message 802 MUST meet the following requirements. 804 o The CertificateVerify.algorithm field SHOULD contain only the 805 signature schemes with the values defined in Section 5. 807 o The CertificateVerify.signature field contains sgn value, which is 808 computed as follows: 810 sgn = SIGN(M, d_sign), 812 o where 814 * function SIGN is defined in Section 5, 816 * structure of M is defined in Section 4.4.3 of [RFC8446], 818 * d_sign is the sender long-term private key that corresponds to 819 the sender long-term public key Q_sign from the sender's 820 certificate. 822 7. IANA Considerations 824 IANA is asked to assign numbers TBD1, TBD2, TBD3 and TBD4 with the 825 names TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L, 826 TLS_GOSTR341112_256_WITH_MAGMA_MGM_L, 827 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S, 828 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S to the "TLS Cipher Suites" 829 registry with this document as reference, as shown below. 831 +-----+-----------------------------------------+-------+----------+ 832 |Value| Description |DTLS-OK| Reference| 833 +-----+-----------------------------------------+-------+----------+ 834 |TBD1 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L| ? | this RFC | 835 +-----+-----------------------------------------+-------+----------+ 836 |TBD2 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L | ? | this RFC | 837 +-----+-----------------------------------------+-------+----------+ 838 |TBD3 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S| ? | this RFC | 839 +-----+-----------------------------------------+-------+----------+ 840 |TBD4 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | ? | this RFC | 841 +-----+-----------------------------------------+-------+----------+ 842 Table 6 844 IANA is asked to assign numbers TBD5, TBD6, TBD7, TBD8, TBD9, TBD10 845 and TBD11 with the names gostr34102012_256a, gostr34102012_256b, 846 gostr34102012_256c, gostr34102012_256d, gostr34102012_512a, 847 gostr34102012_512b, gostr34102012_512c to the "TLS 848 SignatureAlgorithm" registry, as shown below. 850 +-----------+----------------------+---------+----------+ 851 | Value | Description | DTLS-OK | Reference| 852 +-----------+----------------------+---------+----------+ 853 | TBD5 | gostr34102012_256a | ? | this RFC | 854 +-----------+----------------------+---------+----------+ 855 | TBD6 | gostr34102012_256b | ? | this RFC | 856 +-----------+----------------------+---------+----------+ 857 | TBD7 | gostr34102012_256c | ? | this RFC | 858 +-----------+----------------------+---------+----------+ 859 | TBD8 | gostr34102012_256d | ? | this RFC | 860 +-----------+----------------------+---------+----------+ 861 | TBD9 | gostr34102012_512a | ? | this RFC | 862 +-----------+----------------------+---------+----------+ 863 | TBD10 | gostr34102012_512b | ? | this RFC | 864 +-----------+----------------------+---------+----------+ 865 | TBD11 | gostr34102012_512c | ? | this RFC | 866 +-----------+----------------------+---------+----------+ 867 Table 7 869 8. Historical considerations 871 Due to historical reasons in addition to the curve identifier values 872 listed in Table 5 there exist some extra identifier values that 873 correspond to the signature schemes as follows. 875 +--------------------+-------------------------------------------+ 876 | Description | Curve Identifier Value | 877 +--------------------+-------------------------------------------+ 878 | gostr34102012_256b | id-GostR3410_2001-CryptoPro-XchA-ParamSet | 879 | | id-tc26-gost-3410-2012-256-paramSetB | 880 +--------------------+-------------------------------------------+ 881 | gostr34102012_256c | id-tc26-gost-3410-2012-256-paramSetC | 882 +--------------------+-------------------------------------------+ 883 | gostr34102012_256d | id-GostR3410-2001-CryptoPro-XchB-ParamSet | 884 | | id-tc26-gost-3410-2012-256-paramSetD | 885 +--------------------+-------------------------------------------+ 886 Table 8 888 Client should be prepared to handle any of them correctly if 889 corresponding signature scheme is included in the 890 signature_algorithms or signature_algorithms_cert extensions. 892 9. Security Considerations 894 In order to create an effective implementation and to resist attacks 895 client and server SHOULD stick to the following rules. 897 1. While using TLSTREE algorithm function KDF_j, j = 1, 2, 3, SHOULD 898 be invoked only if sequence number seqnum reaches such value that 900 seqnum & C_j != (seqnum - 1) & C_j. 902 Otherwise the previous value should be used. 904 2. For each pre-shared key value PSK the binder_key value should be 905 computed only once within all connections where ClientHello message 906 contains a pre_shared_key extension indicating this PSK value. 908 3. Server SHOULD NOT send Application Data prior to receiving first 909 client's Finished message in a mutually authenticated connection. 911 10. References 913 10.1. Normative References 915 [DraftGostTLS12] 916 Smyshlyaev, S., Belyavsky, D., and M. Saarinen, "GOST 917 Cipher Suites for Transport Layer Security (TLS) Protocol 918 Version 1.2", 2019, . 921 [DraftMGM] 922 Smyshlyaev, S., Nozdrunov, V., Shishkin, V., and E. 923 Smyshlyaeva, "Multilinear Galois Mode (MGM)", 2018, 924 . 926 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 927 Requirement Levels", BCP 14, RFC 2119, 928 DOI 10.17487/RFC2119, March 1997, 929 . 931 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 932 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 933 2013, . 935 [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: 936 Digital Signature Algorithm", RFC 7091, 937 DOI 10.17487/RFC7091, December 2013, 938 . 940 [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher 941 "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, 942 . 944 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 945 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 946 on the Cryptographic Algorithms to Accompany the Usage of 947 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 948 RFC 7836, DOI 10.17487/RFC7836, March 2016, 949 . 951 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 952 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 953 . 955 [RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric 956 Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, 957 . 959 10.2. Informative References 961 [GOST3410-2012] 962 Federal Agency on Technical Regulating and Metrology, 963 "Information technology. Cryptographic data security. 964 Signature and verification processes of [electronic] 965 digital signature", GOST R 34.10-2012, 2012. 967 [GOST3411-2012] 968 Federal Agency on Technical Regulating and Metrology, 969 "Information technology. Cryptographic Data Security. 970 Hashing function", GOST R 34.11-2012, 2012. 972 [GOST3412-2015] 973 Federal Agency on Technical Regulating and Metrology, 974 "Information technology. Cryptographic data security. 975 Block ciphers", GOST R 34.12-2015, 2015. 977 Appendix A. Test Examples 979 TODO 981 Appendix B. Contributors 983 o Lilia Akhmetzyanova 984 CryptoPro 985 lah@cryptopro.ru 987 o Alexandr Sokolov 988 CryptoPro 989 sokolov@cryptopro.ru 991 o Vasily Nikolaev 992 CryptoPro 993 nikolaev@cryptopro.ru 995 Appendix C. Acknowledgments 997 Authors' Addresses 999 Stanislav Smyshlyaev (editor) 1000 CryptoPro 1001 18, Suschevsky val 1002 Moscow 127018 1003 Russian Federation 1005 Phone: +7 (495) 995-48-20 1006 Email: svs@cryptopro.ru 1007 Evgeny Alekseev 1008 CryptoPro 1009 18, Suschevsky val 1010 Moscow 127018 1011 Russian Federation 1013 Email: alekseev@cryptopro.ru 1015 Ekaterina Smyshlyaeva 1016 CryptoPro 1017 18, Suschevsky val 1018 Moscow 127018 1019 Russian Federation 1021 Email: ess@cryptopro.ru 1023 Alexandra Babueva 1024 CryptoPro 1025 18, Suschevsky val 1026 Moscow 127018 1027 Russian Federation 1029 Email: babueva@cryptopro.ru