idnits 2.17.1 draft-smyshlyaev-tls13-gost-suites-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 (June 10, 2021) is 1050 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 356 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. Griboedova 5 Expires: December 12, 2021 A. Babueva 6 CryptoPro 7 June 10, 2021 9 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 10 1.3 11 draft-smyshlyaev-tls13-gost-suites-04 13 Abstract 15 The purpose of this document is to make the Russian cryptographic 16 standards available to the Internet community for their 17 implementation in the Transport Layer Security (TLS) Protocol Version 18 1.3. 20 This specification defines four new cipher suites and seven new 21 signature schemes based on GOST R 34.12-2015, GOST R 34.11-2012 and 22 GOST R 34.10-2012 algorithms. This document does not imply IETF 23 endorsement of the cipher suites. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 12, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 61 3. Basic Terms and Definitions . . . . . . . . . . . . . . . . . 4 62 4. Cipher Suite Definition . . . . . . . . . . . . . . . . . . . 6 63 4.1. Record Protection Algorithm . . . . . . . . . . . . . . . 6 64 4.1.1. AEAD Algorithm . . . . . . . . . . . . . . . . . . . 7 65 4.1.2. TLSTREE . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.1.3. SNMAX parameter . . . . . . . . . . . . . . . . . . . 10 67 4.2. Hash Algorithm . . . . . . . . . . . . . . . . . . . . . 10 68 5. Signature Scheme Definition . . . . . . . . . . . . . . . . . 11 69 5.1. Signature Algorithm . . . . . . . . . . . . . . . . . . . 11 70 5.2. Elliptic Curve . . . . . . . . . . . . . . . . . . . . . 12 71 5.3. SIGN function . . . . . . . . . . . . . . . . . . . . . . 13 72 6. Key Exchange and Authentication . . . . . . . . . . . . . . . 13 73 6.1. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1.1. ECDHE Shared Secret Calculation . . . . . . . . . . . 14 75 6.1.1.1. ECDHE Shared Secret Calculation on Client Side . 14 76 6.1.1.2. ECDHE Shared Secret Calculation on Server Side . 16 77 6.1.1.3. Public ephemeral key representation . . . . . . . 17 78 6.1.2. Values for the TLS Supported Groups Registry . . . . 17 79 6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 18 80 6.3. Handshake Messages . . . . . . . . . . . . . . . . . . . 19 81 6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 19 82 6.3.2. CertificateRequest . . . . . . . . . . . . . . . . . 20 83 6.3.3. Certificate . . . . . . . . . . . . . . . . . . . . . 20 84 6.3.4. CertificateVerify . . . . . . . . . . . . . . . . . . 21 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 86 8. Historical considerations . . . . . . . . . . . . . . . . . . 23 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 90 10.2. Informative References . . . . . . . . . . . . . . . . . 25 91 Appendix A. Test Examples . . . . . . . . . . . . . . . . . . . 26 92 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 26 93 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 26 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 96 1. Introduction 98 This document defines four new cipher suites (the TLS13_GOST cipher 99 suites) and seven new signature schemes (the TLS13_GOST signature 100 schemes) for the Transport Layer Security (TLS) Protocol Version 1.3, 101 that are based on Russian cryptographic standards GOST R 34.12-2015 102 [GOST3412-2015] (the English version can be found in [RFC7801]), GOST 103 R 34.11-2012 [GOST3411-2012] (the English version can be found in 104 [RFC6986]) and GOST R 34.10-2012 [GOST3410-2012] (the English version 105 can be found in [RFC7091]). 107 The TLS13_GOST cipher suites (see Section 4) have the following 108 values: 110 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}; 111 TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04}; 112 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05}; 113 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}. 115 Each TLS13_GOST cipher suite specifies a pair (record protection 116 algorithm, hash algorithm) such that: 118 o The record protection algorithm is the AEAD algorithm (see 119 Section 4.1.1) based on the GOST R 34.12-2015 block cipher 120 [RFC7801] in the Multilinear Galois Mode (MGM) [DraftMGM] and the 121 external re-keying approach (see [RFC8645]) intended for 122 increasing the lifetime of symmetric keys used to protect records. 124 o The hash algorithm is the GOST R 34.11-2012 algorithm [RFC6986]. 126 Note: The TLS13_GOST cipher suites are divided into two types 127 (depending on the key lifetime limitations, see Section 4.1.2 and 128 Section 4.1.3): the "_S" (strong) cipher suites and the "_L" (light) 129 cipher suites. 131 The TLS13_GOST signature schemes that can be used with the TLS13_GOST 132 cipher suites have the following values: 134 gostr34102012_256a = 0x0709; 136 gostr34102012_256b = 0x070A; 138 gostr34102012_256c = 0x070B; 140 gostr34102012_256d = 0x070C; 142 gostr34102012_512a = 0x070D; 143 gostr34102012_512b = 0x070E; 145 gostr34102012_512c = 0x070F. 147 Each TLS13_GOST signature scheme specifies a pair (signature 148 algorithm, elliptic curve) such that: 150 o The signature algorithm is the GOST R 34.10-2012 algorithm 151 [RFC7091]. 153 o The elliptic curve is one of the curves defined in Section 5.2. 155 Additionally, this document specifies the key exchange and 156 authentication process in case of negotiating TLS13_GOST cipher 157 suites (see Section 6). 159 2. Conventions Used in This Document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 3. Basic Terms and Definitions 169 This document uses the following terms and definitions for the sets 170 and operations on the elements of these sets: 172 B_t the set of byte strings of length t, t >= 0, for t = 173 0 the B_t set consists of a single empty string of 174 zero length. If A is an element of B_t, then A = 175 (a_1, a_2, ... , a_t), where a_1, a_2, ... , a_t are 176 in {0, ... , 255}; 178 B* the set of all byte strings of a finite length 179 (hereinafter referred to as strings), including the 180 empty string; 182 A[i..j] the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in 183 B_{j-i+1}, where A = (a_1, a_2, ... , a_t) in B_t and 184 1<=i<=j<=t; 186 A[i] the integer a_i in {0, ... , 255}, where A = (a_1, 187 a_2, ... , a_t) in B_t and 1<=i<=t; 189 |A| the byte length of the string A; 190 A | C the concatenation of strings A and C both belonging 191 to B*, i.e., a string in B_{|A|+|C|}, where the left 192 substring in B_|A| is equal to A, and the right 193 substring in B_|C| is equal to C; 195 i & j bitwise AND of integers i and j; 197 STR_t the byte string STR_t(i) = (i_1, ... , i_t) in B_t 198 corresponding to an integer i = 256^{t-1} * i_1 + ... 199 + 256 * i_{t-1} + i_t (the interpretation of the 200 integer as a byte string in big-endian format); 202 str_t the byte string str_t(i) = (i_1, ... , i_t) in B_t 203 corresponding to an integer i = 256^{t-1} * i_t + ... 204 + 256 * i_2 + i_1 (the interpretation of the integer 205 as a byte string in little-endian format); 207 k the length of the block cipher key in bytes; 209 n the length of the block cipher block in bytes; 211 IVlen the length of the initialization vector in bytes; 213 S the length of the authentication tag in bytes; 215 E_i the elliptic curve indicated by client in 216 "supported_groups" extension; 218 O_i the zero point of the elliptic curve E_i; 220 m_i the order of group of points belonging to the 221 elliptic curve E_i; 223 q_i the cyclic subgroup order of group of points 224 belonging to the elliptic curve E_i; 226 h_i the cyclic subgroup cofactor which is equal to m_i / 227 q_i; 229 Q_sign the public key stored in endpoint's certificate; 231 d_sign the private key that corresponds to the Q_sign key; 233 P_i the point of the elliptic curve E_i of the order q_i; 235 (d_C^i, Q_C^i) the client's ephemeral key pair which consists of the 236 private key and the public key corresponding to the 237 elliptic curve E_i; 239 (d_S^i, Q_S^i) the server's ephemeral key pair which consists of the 240 private key and the public key corresponding to the 241 elliptic curve E_i. 243 4. Cipher Suite Definition 245 The cipher suite value is used to indicate a record protection 246 algorithm and a hash algorithm which an endpoint supports (see 247 Section 4.1.2 of [RFC8446]). 249 This section defines the following four TLS13_GOST cipher suites that 250 can be used to support Russian cryptographic algorithms: 252 CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}; 253 CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04}; 254 CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05}; 255 CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}; 257 Each cipher suite specifies a pair of the record protection algorithm 258 (see Section 4.1) and the hash algorithm (Section 4.2). 260 4.1. Record Protection Algorithm 262 In accordance with Section 5.2 of [RFC8446] the record protection 263 algorithm translates a TLSPlaintext structure into a TLSCiphertext 264 structure. If TLS13_GOST cipher suite is negotiated, the 265 encrypted_record field of the TLSCiphertext structure MUST be set to 266 the AEADEncrypted value computed as follows: 268 AEADEncrypted = AEAD-Encrypt(sender_record_write_key, nonce, 269 associated_data, plaintext), 271 where 273 o the AEAD-Encrypt function is defined in Section 4.1.1; 275 o the sender_record_write_key is derived from the sender_write_key 276 (see Section 7.3 of [RFC8446]) using TLSTREE function defined in 277 Section 4.1.2 and sequence number seqnum as follows: 279 sender_record_write_key = TLSTREE(sender_write_key, seqnum); 281 o the nonce value is derived from the record sequence number seqnum 282 and the sender_write_iv value (see Section 7.3 of [RFC8446]) in 283 accordance with Section 5.3 of [RFC8446]; 285 o the associated_data value is the record header that is generated 286 in accordance with Section 5.2 of [RFC8446]; 288 o the plaintext value is the TLSInnerPlaintext structure encoded in 289 accordance with Section 5.2 of [RFC8446]. 291 Note1: The AEAD-Encrypt function is exactly the same as the AEAD- 292 Encrypt function defined in [RFC8446] except the key (the first 293 argument) is calculated from the sender_write_key and sequence number 294 seqnum for each message separately to support external re-keying 295 approach according to [RFC8645]. 297 Note2: The record sequence number is the value in the range 0-SNMAX, 298 where the SNMAX value is defined in Section 4.1.3. The SNMAX 299 parameter is specified by the particular TLS13_GOST cipher suite to 300 limit the amount of data that can be encrypted under the same traffic 301 key material (sender_write_key, sender_write_iv). 303 The record deprotection algorithm reverses the process of the record 304 protection. In order to decrypt and verify the protected record with 305 sequence number seqnum the algorithm takes as input the 306 sender_record_write_key is derived from the sender_write_key, nonce, 307 associated_data and the AEADEncrypted value and outputs the res value 308 which is either the plaintext or an error indicating that the 309 decryption failed. If TLS13_GOST cipher suite is negotiated, the res 310 value MUST be computed as follows: 312 res = AEAD-Decrypt(sender_record_write_key, nonce, 313 associated_data, AEADEncrypted), 315 where the AEAD-Decrypt function is defined in Section 4.1.1. 317 Note: The AEAD-Decrypt function is exactly the same as the AEAD- 318 Decrypt function defined in [RFC8446] except the key (the first 319 argument) is calculated from the sender_write_key and sequence number 320 seqnum for each message separately to support external re-keying 321 approach according to [RFC8645]. 323 4.1.1. AEAD Algorithm 325 The AEAD-Encrypt and AEAD-Decrypt functions are defined as follows. 327 +-------------------------------------------------------------------+ 328 | AEAD-Encrypt(K, nonce, A, P) | 329 |-------------------------------------------------------------------| 330 | Input: | 331 | - encryption key K in B_k, | 332 | - unique vector nonce in B_IVlen, | 333 | - associated authenticated data A in B_r, r >= 0, | 334 | - plaintext P in B_t, t >= 0. | 335 | Output: | 336 | - ciphertext C in B_{|P|}, | 337 | - authentication tag T in B_S. | 338 |-------------------------------------------------------------------| 339 | 1. MGMnonce = STR_1(nonce[1] & 0x7f) | nonce[2..IVlen]; | 340 | 2. (MGMnonce, A, C, T) = MGM-Encrypt(K, MGMnonce, A, P); | 341 | 3. Return C | T. | 342 +-------------------------------------------------------------------+ 344 +-------------------------------------------------------------------+ 345 | AEAD-Decrypt(K, nonce, A, C | T) | 346 |-------------------------------------------------------------------| 347 | Input: | 348 | - encryption key K in B_k, | 349 | - unique vector nonce in B_IVlen, | 350 | - associated authenticated data A in B_r, r >= 0, | 351 | - ciphertext C in B_t, t >= 0, | 352 | - authentication tag T in B_S. | 353 | Output: | 354 | - plaintext P in B_{|C|} or FAIL. | 355 |-------------------------------------------------------------------| 356 | 1. MGMnonce = STR_1(nonce[1] & 0x7f) | nonce[2..IVlen]; | 357 | 2. res' = MGM-Decrypt(K, MGMnonce, A, C, T); | 358 | 3. IF res' = FAIL then return FAIL; | 359 | 4. IF res' = (A, P) then return P. | 360 +-------------------------------------------------------------------+ 362 where 364 o MGM-Encrypt and MGM-Decrypt functions are defined in [DraftMGM]. 365 The size of the authentication tag T is equal to n bytes (S = n). 366 The size of the nonce parameter is equal to n bytes (IVlen = n). 368 The cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and 369 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik 370 [RFC7801] as a base block cipher for the AEAD algorithm. The block 371 length n is 16 bytes (n = 16) and the key length k is 32 bytes (k = 372 32). 374 The cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and 375 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST use Magma [GOST3412-2015] 376 as a base block cipher for the AEAD algorithm. The block length n is 377 8 bytes (n = 8) and the key length k is 32 bytes (k = 32). 379 4.1.2. TLSTREE 381 The TLS13_GOST cipher suites use the TLSTREE function for the 382 external re-keying approach (see [RFC8645]). The TLSTREE function is 383 defined as follows: 385 TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8(i & C_1)), 386 STR_8(i & C_2)), STR_8(i & C_3)), 388 where 390 o K_root in B_32; 392 o i in {0, 1, ... , 2^64 - 1}; 394 o KDF_j(K, D), j = 1, 2, 3, is the key derivation function defined 395 as follows: 397 KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D), 398 KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D), 399 KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D), 401 where the KDF_GOSTR3411_2012_256 function is defined in [RFC7836], 402 K in B_32, D in B_8. 404 o C_1, C_2, C_3 are constants defined by the particular cipher suite 405 as follows: 407 +------------------------------------------+----------------------+ 408 | CipherSuites | C_1, C_2, C_3 | 409 +------------------------------------------+----------------------+ 410 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L |C_1=0xf800000000000000| 411 | |C_2=0xfffffff000000000| 412 | |C_3=0xffffffffffffe000| 413 +------------------------------------------+----------------------+ 414 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L |C_1=0xffe0000000000000| 415 | |C_2=0xffffffffc0000000| 416 | |C_3=0xffffffffffffff80| 417 +------------------------------------------+----------------------+ 418 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S |C_1=0xffffffffe0000000| 419 | |C_2=0xffffffffffff0000| 420 | |C_3=0xfffffffffffffff8| 421 +------------------------------------------+----------------------+ 422 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S |C_1=0xfffffffffc000000| 423 | |C_2=0xffffffffffffe000| 424 | |C_3=0xffffffffffffffff| 425 +------------------------------------------+----------------------+ 426 Table 1 428 4.1.3. SNMAX parameter 430 The SNMAX parameter is the maximum number of records encrypted under 431 the same traffic key material (sender_write_key and sender_write_iv) 432 and is defined by the particular cipher suite as follows: 434 +------------------------------------------+--------------------+ 435 | CipherSuites | SNMAX | 436 +------------------------------------------+--------------------+ 437 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L | SNMAX = 2^64 - 1 | 438 +------------------------------------------+--------------------+ 439 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L | SNMAX = 2^64 - 1 | 440 +------------------------------------------+--------------------+ 441 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S | SNMAX = 2^42 - 1 | 442 +------------------------------------------+--------------------+ 443 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | SNMAX = 2^39 - 1 | 444 +------------------------------------------+--------------------+ 445 Table 2 447 4.2. Hash Algorithm 449 The Hash algorithm is used for key derivation process (see 450 Section 7.1 of [RFC8446]), Finished message calculation (see 451 Section 4.4.4 of [RFC8446]), Transcript-Hash function computation 452 (see Section 4.4.1 of [RFC8446]), PSK binder value calculation (see 453 Section 4.2.11.2 of [RFC8446]), external re-keying approach (see 454 Section 4.1.2) and other purposes. 456 In case of negotiating a TLS13_GOST cipher suite the Hash algorithm 457 MUST be the GOST R 34.11-2012 [RFC6986] hash algorithm with 32-byte 458 (256-bit) hash value. 460 5. Signature Scheme Definition 462 The signature scheme value is used to indicate a single signature 463 algorithm and a curve that can be used in digital signature (see 464 Section 4.2.3 of [RFC8446]). 466 This section defines the following seven TLS13_GOST signature schemes 467 that can be used to support Russian cryptographic algorithms: 469 enum { 470 gostr34102012_256a(0x0709), 471 gostr34102012_256b(0x070A), 472 gostr34102012_256c(0x070B), 473 gostr34102012_256d(0x070C), 474 gostr34102012_512a(0x070D), 475 gostr34102012_512b(0x070E), 476 gostr34102012_512c(0x070F) 477 } SignatureScheme; 479 If TLS13_GOST cipher suite is negotiated and authentication via 480 certificates is required one of the TLS13_GOST signature schemes 481 listed above SHOULD be used. 483 Each signature scheme specifies a pair of the signature algorithm 484 (see Section 5.1) and the elliptic curve (see Section 5.2). The 485 procedure to calculate the signature value using TLS13_GOST signature 486 schemes is defined in Section 5.3. 488 5.1. Signature Algorithm 490 Signature algorithms corresponding to the TLS13_GOST signature 491 schemes are defined as follows: 493 +------------------+--------------------------------------+--------+ 494 | SignatureScheme | Signature Algorithm | Refe- | 495 | Value | | rences | 496 +------------------+--------------------------------------+--------+ 497 |gostr34102012_256a|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 498 +------------------+--------------------------------------+--------+ 499 |gostr34102012_256b|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 500 +------------------+--------------------------------------+--------+ 501 |gostr34102012_256c|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 502 +------------------+--------------------------------------+--------+ 503 |gostr34102012_256d|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 504 +------------------+--------------------------------------+--------+ 505 |gostr34102012_512a|GOST R 34.10-2012 , 64-byte key length|RFC 7091| 506 +------------------+--------------------------------------+--------+ 507 |gostr34102012_512b|GOST R 34.10-2012 , 64-byte key length|RFC 7091| 508 +------------------+--------------------------------------+--------+ 509 |gostr34102012_512c|GOST R 34.10-2012 , 64-byte key length|RFC 7091| 510 +------------------+--------------------------------------+--------+ 511 Table 3 513 5.2. Elliptic Curve 515 Elliptic curves corresponding to the TLS13_GOST signature schemes are 516 defined as follows: 518 +------------------+--------------------------------------+--------+ 519 | SignatureScheme | Curve Identifier Value | Refe- | 520 | Value | | rences | 521 +------------------+--------------------------------------+--------+ 522 |gostr34102012_256a| id-tc26-gost-3410-2012-256-paramSetA |RFC 7836| 523 +------------------+--------------------------------------+--------+ 524 |gostr34102012_256b|id-GostR3410-2001-CryptoPro-A-ParamSet|RFC 4357| 525 +------------------+--------------------------------------+--------+ 526 |gostr34102012_256c|id-GostR3410-2001-CryptoPro-B-ParamSet|RFC 4357| 527 +------------------+--------------------------------------+--------+ 528 |gostr34102012_256d|id-GostR3410-2001-CryptoPro-C-ParamSet|RFC 4357| 529 +------------------+--------------------------------------+--------+ 530 |gostr34102012_512a| id-tc26-gost-3410-12-512-paramSetA |RFC 7836| 531 +------------------+--------------------------------------+--------+ 532 |gostr34102012_512b| id-tc26-gost-3410-12-512-paramSetB |RFC 7836| 533 +------------------+--------------------------------------+--------+ 534 |gostr34102012_512c| id-tc26-gost-3410-2012-512-paramSetC |RFC 7836| 535 +------------------+--------------------------------------+--------+ 536 Table 4 538 5.3. SIGN function 540 If TLS13_GOST signature scheme is used, the signature value in 541 CertificateVerify message (see Section 6.3.4) MUST be calculated 542 using the SIGN function defined as follows: 544 +-----------------------------------------------------+ 545 | SIGN(d_sign, M) | 546 |-----------------------------------------------------| 547 | Input: | 548 | - the sign key d_sign: 0 < d_sign < q; | 549 | - the byte string M in B*. | 550 | Output: | 551 | - signature value sgn in B_{2*l}. | 552 |-----------------------------------------------------| 553 | 1. (r, s) = SIGNGOST(d_sign, M) | 554 | 2. Return str_l(r) | str_l(s). | 555 |-----------------------------------------------------+ 557 where 559 o q is the subgroup order of group of points of the elliptic curve; 561 o l is defined as follows: 563 * l = 32 for gostr34102012_256a, gostr34102012_256b, 564 gostr34102012_256c and gostr34102012_256d signature schemes; 566 * l = 64 for gostr34102012_512a, gostr34102012_512b and 567 gostr34102012_512c signature schemes; 569 o SIGNGOST is an algorithm which takes as an input private key 570 d_sign and message M and returns a pair of integers (r, s) 571 calculated during signature generation process in accordance with 572 the GOST R 34.10-2012 signature algorithm (see Section 6.1 of 573 [RFC7091]). 575 Note: The signature value sgn is the concatenation of two strings 576 that are byte representations of r and s values in the little-endian 577 format. 579 6. Key Exchange and Authentication 581 Key exchange and authentication process in case of using TLS13_GOST 582 cipher suites is defined in Section 6.1, Section 6.2 and Section 6.3. 584 6.1. Key Exchange 586 TLS13_GOST cipher suites support three basic key exchange modes which 587 are defined in [RFC8446]: ECDHE, PSK-only and PSK-with-ECDHE. 589 Note: In accordance with [RFC8446] TLS 1.3 also supports key exchange 590 modes based on Diffie-Hellman protocol over finite fields. However, 591 TLS13_GOST cipher suites MUST use only modes based on Diffie-Hellman 592 protocol over elliptic curves. 594 In accordance with [RFC8446] PSKs can be divided into two types: 596 o internal PSKs which can be established during the previous 597 connection; 599 o external PSKs which can be established out of band. 601 If TLS13_GOST cipher suite is negotiated, PSK-only key exchange mode 602 SHOULD be established only via the internal PSKs, and external PSKs 603 SHOULD be used only in PSK-with-ECDHE mode (see more in Section 9). 605 If TLS13_GOST cipher suite is negotiated and ECDHE or PSK-with-ECDHE 606 key exchange mode is used the ECDHE shared secret value should be 607 calculated in accordance with Section 6.1.1 on the basis of one of 608 the elliptic curves defined in Section 6.1.2. 610 6.1.1. ECDHE Shared Secret Calculation 612 If TLS13_GOST cipher suite is negotiated, ECDHE shared secret value 613 should be calculated in accordance with Section 6.1.1.1 and 614 Section 6.1.1.2. The public ephemeral keys used to obtain ECDHE 615 shared secret value should be represented in format described in 616 Section 6.1.1.3. 618 6.1.1.1. ECDHE Shared Secret Calculation on Client Side 620 The client calculates ECDHE shared secret value in accordance with 621 the following steps: 623 1. Chooses from all supported curves E_1, ..., E_R the set of curves 624 E_{i_1}, ..., E_{i_r}, 1 <= i_1 <= i_r <= R, where 626 o r >= 1 in the case of the first ClientHello message; 628 o r = 1 in the case of responding to HelloRetryRequest message, 629 E_{i_1} corresponds to the curve indicated in the "key_share" 630 extension in the HelloRetryRequest message. 632 2. Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ..., 633 (d_C^{i_r}, Q_C^{i_r}) corresponding to the curves E_{i_1}, ..., 634 E_{i_r}, where for each i in {i_1, ..., i_r}: 636 o d_C^i is chosen from {1, ..., q_i - 1} at random; 638 o Q_C^i = d_C^i * P_i. 640 3. Sends ClientHello message specified in accordance with 641 Section 4.1.2 of [RFC8446] and Section 6.3.1, which contains: 643 o "key_share" extension with public ephemeral keys Q_C^{i_1}, ..., 644 Q_C^{i_r} generated in accordance with Section 4.2.8 of [RFC8446]; 646 o "supported_groups" extension with supported curves E_1, ..., E_R 647 generated in accordance with Section 4.2.7 of [RFC8446]. 649 Note: Client MAY send an empty "key_share" extension in the first 650 ClientHello in order to request group selection from the server in 651 the HelloRetryRequest message and to generate ephemeral key for the 652 selected group only. The ECDHE value may be calculated without 653 sending HelloRetryRequest, if the "key_share" extension in the first 654 ClientHello message consists the value corresponded to the curve that 655 will be selected by the server. 657 4. In case of receiving HelloRetryRequest message client MUST return 658 to step 1 and correct parameters in accordance with Section 4.1.2 of 659 [RFC8446]. In case of receiving ServerHello message client proceeds 660 to the next step. In other cases client MUST terminate the 661 connection with "unexpected_message" alert. 663 5. Extracts curve E_res and ephemeral key Q_S^res, res in {1, ..., 664 R}, from ServerHello message and checks whether the Q_S^res belongs 665 to E_res. If this check fails, the client MUST abort the handshake 666 with "handshake_failure" alert. 668 6. Generates Q^ECDHE: 670 Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) * Q_S^res. 672 7. Client MUST check whether the computed shared secret Q^ECDHE is 673 not equal to the zero point O_res. If this check fails, the client 674 MUST abort the handshake with "handshake_failure" alert. 676 8. Shared secret value ECDHE is the byte representation of the 677 coordinate X^ECDHE of point Q^ECDHE in the little-endian format: 679 ECDHE = str_{coordinate_length}(X^ECDHE), 681 where the coordinate_length value is defined by the particular 682 elliptic curve (see Section 6.1.2). 684 6.1.1.2. ECDHE Shared Secret Calculation on Server Side 686 Upon receiving the ClientHello message, the server calculates ECDHE 687 shared secret value in accordance with the following steps: 689 1. Chooses the curve E_res, res in {1, ..., R}, from the list of the 690 curves E_1, ..., E_R indicated in "supported_groups" extension in 691 ClientHello message and the corresponding public ephemeral key value 692 Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r}, 1 <= i_1 <= i_r <= 693 R, indicated in "key_share" extension. If no corresponding public 694 ephemeral key value is found (res in {1, ..., R}\{i_1, ..., i_r}), 695 server MUST send HelloRetryRequest message with "key_share" extension 696 indicating the selected elliptic curve E_res and wait for the new 697 ClientHello message. 699 2. Checks whether Q_C^res belongs to E_res. If this check fails, 700 the server MUST abort the handshake with "handshake_failure" alert. 702 3. Generates ephemeral key pair (d_S^res, Q_S^res) corresponding to 703 E_res: 705 o d_S^res is chosen from {1, ..., q_res - 1} at random; 707 o Q_S^res = d_S^res * P_res. 709 4. Sends ServerHello message generated in accordance with 710 Section 4.1.3 of [RFC8446] and Section 6.3.1 with "key_share" 711 extension which contains public ephemeral key value Q_S^res 712 corresponding to E_res. 714 5. Generates Q^ECDHE: 716 Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res. 718 6. Server MUST check whether the computed shared secret Q^ECDHE is 719 not equal to the zero point O_res. If this check fails, the server 720 MUST abort the handshake with "handshake_failure" alert. 722 7. Shared secret value ECDHE is the byte representation of the 723 coordinate X^ECDHE of point Q^ECDHE in the little-endian format: 725 ECDHE = str_{coordinate_length}(X^ECDHE), 727 where the coordinate_length value is defined by the particular 728 elliptic curve (see Section 6.1.2). 730 6.1.1.3. Public ephemeral key representation 732 This section defines the representation format of the public 733 ephemeral keys generated during ECDHE shared secret calculation (see 734 Section 6.1.1.1 and Section 6.1.1.2). 736 If TLS13_GOST cipher suite is negotiated and ECDHE or PSK-with-ECDHE 737 key exchange mode is used, the public ephemeral key Q indicated in 738 the KeyShareEntry.key_exchange field MUST contain the data defined by 739 the following structure: 741 struct { 742 opaque X[coordinate_length]; 743 opaque Y[coordinate_length]; 744 } PlainPointRepresentation; 746 where X and Y, respectively, contain the byte representations of the 747 x and the y values of point Q (Q = (x, y)) in the little-endian 748 format and are specified as follows: 750 X = str_{coordinate_length}(x); 752 Y = str_{coordinate_length}(y). 754 The coordinate_length value is defined by the particular elliptic 755 curve (see Section 6.1.2). 757 6.1.2. Values for the TLS Supported Groups Registry 759 The "supported_groups" extension is used to indicate the set of the 760 elliptic curves supported by an endpoint and is defined in 761 Section 4.2.7 [RFC8446]. This extension is always contained in 762 ClientHello message and optionally in EncryptedExtensions message. 764 This section defines the following seven elliptic curves that can be 765 used to support Russian cryptographic algorithms: 767 enum { 768 GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25), 769 GC512A(0x26), GC512B(0x27), GC512C(0x28) 770 } NamedGroup; 771 If TLS13_GOST cipher suite is negotiated and ECDHE or PSK-with-ECDHE 772 key exchange mode is established, one of the elliptic curves listed 773 above SHOULD be used. 775 Each curve corresponds to the particular identifier and specifies the 776 value of coordinate_length parameter (see "cl" column) as follows: 778 +-----------+--------------------------------------+----+---------+ 779 |Description| Curve Identifier Value | cl |Reference| 780 +-----------+--------------------------------------+----+---------+ 781 | GC256A | id-tc26-gost-3410-2012-256-paramSetA | 32 | RFC 7836| 782 +-----------+--------------------------------------+----+---------+ 783 | GC256B |id-GostR3410-2001-CryptoPro-A-ParamSet| 32 | RFC 4357| 784 +-----------+--------------------------------------+----+---------+ 785 | GC256C |id-GostR3410-2001-CryptoPro-B-ParamSet| 32 | RFC 4357| 786 +-----------+--------------------------------------+----+---------+ 787 | GC256D |id-GostR3410-2001-CryptoPro-C-ParamSet| 32 | RFC 4357| 788 +-----------+--------------------------------------+----+---------+ 789 | GC512A | id-tc26-gost-3410-12-512-paramSetA | 64 | RFC 7836| 790 +-----------+--------------------------------------+----+---------+ 791 | GC512B | id-tc26-gost-3410-12-512-paramSetB | 64 | RFC 7836| 792 +-----------+--------------------------------------+----+---------+ 793 | GC512C | id-tc26-gost-3410-2012-512-paramSetC | 64 | RFC 7836| 794 +-----------+--------------------------------------+----+---------+ 795 Table 5 797 Note: The identifier values and the corresponding elliptic curves are 798 the same as in [DraftGostTLS12]. 800 6.2. Authentication 802 In accordance with [RFC8446] authentication can happen via signature 803 with certificate or via symmetric pre-shared key (PSK). The server 804 side of the channel is always authenticated; the client side is 805 optionally authenticated. 807 PSK-based authentication happens as a side effect of key exchange. 808 If TLS13_GOST cipher suite is negotiated, external PSKs SHOULD be 809 combined only with the mutual authentication (see more in Section 9). 811 Certificate-based authentication happens via Authentication messages 812 and optional CertificateRequest message (sent if client 813 authentication is required). In case of negotiating TLS13_GOST 814 cipher suites the signature schemes used for certificate-based 815 authentication are defined in Section 5 and the Authentication 816 messages are specified in Section 6.3.3 and Section 6.3.4. The 817 CertificateRequest message is specified in Section 6.3.2. 819 6.3. Handshake Messages 821 The TLS13_GOST cipher suites specify the ClientHello, ServerHello, 822 CertificateRequest, Certificate and CertificateVerify handshake 823 messages that are described in further detail below. 825 6.3.1. Hello Messages 827 The ClientHello message is sent when a client first connects to a 828 server or responds to a HelloRetryRequest message and is specified in 829 accordance with Section 4.1.2 of [RFC8446]. 831 In order to negotiate a TLS13_GOST cipher suite, the ClientHello 832 message MUST meet the following requirements. 834 o The ClientHello.cipher_suites field MUST contain the values 835 defined in Section 4. 837 o If server authentication via a certificate is required, the 838 extension_data field of the "signature_algorithms" extension MUST 839 contain the values defined in Section 5, which correspond to the 840 GOST R 34.10-2012 signature algorithm. 842 o If server authentication via a certificate is required and the 843 client uses optional "signature_algorithms_cert" extension, the 844 extension_data field of this extension SHOULD contain the values 845 defined in Section 5, which correspond to the GOST R 34.10-2012 846 signature algorithm. 848 o If client wants to establish TLS 1.3 connection using ECDHE shared 849 secret value, the extension_data field of the "supported_groups" 850 extension MUST contain the elliptic curve identifiers defined in 851 Section 6.1.2. 853 The ServerHello message is sent by the server in response to a 854 ClientHello message to negotiate an acceptable set of handshake 855 parameters based on the ClientHello and is specified in accordance 856 with Section 4.1.3 of [RFC8446]. 858 In case of negotiating a TLS13_GOST cipher suite, the ServerHello 859 message MUST meet the following requirements. 861 o The ServerHello.cipher_suite field MUST contain one of the values 862 defined in Section 4. 864 o If server decides to establish TLS 1.3 connection using ECDHE 865 shared secret value, the extension_data field of the "key_share" 866 extension MUST contain the elliptic curve identifier and the 867 public ephemeral key that satisfy the following conditions. 869 * The elliptic curve identifier corresponds to a value that was 870 provided in the "supported_groups" and the "key_share" 871 extensions in the ClientHello message. 873 * The elliptic curve identifier is one of the values defined in 874 Section 6.1.2. 876 * The public ephemeral key corresponds to the elliptic curve 877 specified by the KeyShareEntry.group identifier. 879 6.3.2. CertificateRequest 881 This message is sent when server requests client authentication via a 882 certificate and is specified in accordance with Section 4.3.2 of 883 [RFC8446]. 885 If TLS13_GOST cipher suite is negotiated, the CertificateRequest 886 message MUST meet the following requirements. 888 o The extension_data field of the "signature_algorithms" extension 889 MUST contain only the values defined in Section 5. 891 o If server uses optional "signature_algorithms_cert" extension, the 892 extension_data field of this extension SHOULD contain only the 893 values defined in Section 5. 895 6.3.3. Certificate 897 This message is sent to convey the endpoint's certificate chain to 898 the peer and is specified in accordance with Section 4.4.2 of 899 [RFC8446]. 901 If TLS13_GOST cipher suite is negotiated, the Certificate message 902 MUST meet the following requirements. 904 o Each endpoint's certificate provided to the peer MUST be signed 905 using the algorithm which corresponds to a signature scheme 906 indicated by the peer in its "signature_algoritms_cert" extension, 907 if present (or in the "signature_algorithms" extension, 908 otherwise). 910 o The signature algorithm used for signing certificates SHOULD 911 correspond to the one of the signature schemes defined in 912 Section 5. 914 6.3.4. CertificateVerify 916 This message is sent to provide explicit proof that an endpoint 917 possesses the private key corresponding to the public key indicated 918 in its certificate and is specified in accordance with Section 4.4.3 919 of [RFC8446]. 921 If TLS13_GOST cipher suite is negotiated, the CertificateVerify 922 message MUST meet the following requirements. 924 o The CertificateVerify.algorithm field MUST contain the signature 925 scheme identifier which corresponds to the value indicated in the 926 peer's "signature_algorithms" extension and which is one of the 927 values defined in Section 5. 929 o The CertificateVerify.signature field contains the sgn value, 930 which is computed as follows: 932 sgn = SIGN(d_sign, M), 934 o where 936 * the SIGN function is defined in Section 5.3, 938 * d_sign is the sender long-term private key that corresponds to 939 the sender long-term public key Q_sign from the sender's 940 certificate, 942 * the message M is defined in accordance with Section 4.4.3 of 943 [RFC8446]. 945 7. IANA Considerations 947 IANA has added numbers {0xC1, 0x03}, {0xC1, 0x04}, {0xC1, 0x05} and 948 {0xC1, 0x06} with the names 949 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L, 950 TLS_GOSTR341112_256_WITH_MAGMA_MGM_L, 951 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S, 952 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S to the "TLS Cipher Suites" 953 registry with this document as reference, as shown below. 955 +----------+-----------------------------+-------+-----------+ 956 | Value | Description |DTLS-OK| Reference | 957 +----------+-----------------------------+-------+-----------+ 958 |0xC1, 0x03| TLS_GOSTR341112_256_ | N | this RFC | 959 | | _WITH_KUZNYECHIK_MGM_L | | | 960 +----------+-----------------------------+-------+-----------+ 961 |0xC1, 0x04| TLS_GOSTR341112_256_ | N | this RFC | 962 | | _WITH_MAGMA_MGM_L | | | 963 +----------+-----------------------------+-------+-----------+ 964 |0xC1, 0x05| TLS_GOSTR341112_256_ | N | this RFC | 965 | | _WITH_KUZNYECHIK_MGM_S | | | 966 +----------+-----------------------------+-------+-----------+ 967 |0xC1, 0x06| TLS_GOSTR341112_256_ | N | this RFC | 968 | | _WITH_MAGMA_MGM_S | | | 969 +----------+-----------------------------+-------+-----------+ 970 Table 6 972 IANA has added numbers 0x0709, 0x070A, 0x070B, 0x070C, 0x070D, 0x070E 973 and 0x070F with the names gostr34102012_256a, gostr34102012_256b, 974 gostr34102012_256c, gostr34102012_256d, gostr34102012_512a, 975 gostr34102012_512b, gostr34102012_512c to the "TLS SignatureScheme" 976 registry, as shown below. 978 +-----------+----------------------+---------+----------+ 979 | Value | Description | DTLS-OK | Reference| 980 +-----------+----------------------+---------+----------+ 981 | 0x0709 | gostr34102012_256a | N | this RFC | 982 +-----------+----------------------+---------+----------+ 983 | 0x070A | gostr34102012_256b | N | this RFC | 984 +-----------+----------------------+---------+----------+ 985 | 0x070B | gostr34102012_256c | N | this RFC | 986 +-----------+----------------------+---------+----------+ 987 | 0x070C | gostr34102012_256d | N | this RFC | 988 +-----------+----------------------+---------+----------+ 989 | 0x070D | gostr34102012_512a | N | this RFC | 990 +-----------+----------------------+---------+----------+ 991 | 0x070E | gostr34102012_512b | N | this RFC | 992 +-----------+----------------------+---------+----------+ 993 | 0x070F | gostr34102012_512c | N | this RFC | 994 +-----------+----------------------+---------+----------+ 995 Table 7 997 8. Historical considerations 999 Due to historical reasons in addition to the curve identifier values 1000 listed in Table 5 there exist some additional identifier values that 1001 correspond to the signature schemes as follows. 1003 +--------------------+-------------------------------------------+ 1004 | Description | Curve Identifier Value | 1005 +--------------------+-------------------------------------------+ 1006 | gostr34102012_256b | id-GostR3410_2001-CryptoPro-XchA-ParamSet | 1007 | | id-tc26-gost-3410-2012-256-paramSetB | 1008 +--------------------+-------------------------------------------+ 1009 | gostr34102012_256c | id-tc26-gost-3410-2012-256-paramSetC | 1010 +--------------------+-------------------------------------------+ 1011 | gostr34102012_256d | id-GostR3410-2001-CryptoPro-XchB-ParamSet | 1012 | | id-tc26-gost-3410-2012-256-paramSetD | 1013 +--------------------+-------------------------------------------+ 1014 Table 8 1016 Client should be prepared to handle any of them correctly if 1017 corresponding signature scheme is included in the 1018 "signature_algorithms" or "signature_algorithms_cert" extensions. 1020 9. Security Considerations 1022 In order to create an effective implementation client and server 1023 SHOULD follow the rules below. 1025 1. While using TLSTREE algorithm function KDF_j, j = 1, 2, 3, SHOULD 1026 be invoked only if the record sequence number seqnum reaches such a 1027 value that 1029 seqnum & C_j != (seqnum - 1) & C_j. 1031 Otherwise the previous value should be used. 1033 2. For each pre-shared key value PSK the binder_key value should be 1034 computed only once within all connections where ClientHello message 1035 contains a "pre_shared_key" extension indicating this PSK value. 1037 In order to ensure the secure TLS 1.3 connection client and server 1038 SHOULD fulfil the following requirements. 1040 1. An internal PSK value is NOT RECOMMENDED to be used to establish 1041 more than one TLS 1.3 connection. 1043 2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection. The 1044 reasons for this restriction are that the 0-RTT data is not forward 1045 secret and is not resistant to replay attacks (see more in 1046 Section 2.3 of [RFC8446]). 1048 3. If client authentication is required, server SHOULD NOT send 1049 Application Data, NewSessionTicket and KeyUpdate messages prior to 1050 receiving the client's Authentication messages since any data sent at 1051 that point is being sent to an unauthenticated peer. 1053 4. External PSKs SHOULD be used only in PSK-with-ECDHE mode. In 1054 case of using external PSK in PSK-only mode the attack described in 1055 [Selfie] is possible which leads to the situation when client 1056 establishes connection to itself. One of the mitigations proposed in 1057 [Selfie] is to use certificates, however, in that case, an 1058 impersonation attack as in [AASS19] occurs. If the connections are 1059 established with additional usage of key_share extension (in PSK- 1060 with-ECDHE mode), then the adversary which just echoes messages 1061 cannot reveal the traffic key material (as long as the used group is 1062 secure). 1064 5. In case of using external PSK, the mutual authentication MUST be 1065 provided by the external PSK distribution mechanism between the 1066 endpoints which guarantees that the derived external PSK is unknown 1067 to anyone but the endpoints. In addition, the endpoint roles (i.e. 1068 client and server) MUST be fixed during this mechanism and each role 1069 can match only to one endpoint during the whole external PSK 1070 lifetime. 1072 10. References 1074 10.1. Normative References 1076 [DraftGostTLS12] 1077 Smyshlyaev, S., Belyavsky, D., and M. Saarinen, "GOST 1078 Cipher Suites for Transport Layer Security (TLS) Protocol 1079 Version 1.2", 2021, . 1082 [DraftMGM] 1083 Smyshlyaev, S., Nozdrunov, V., Shishkin, V., and E. 1084 Smyshlyaeva, "Multilinear Galois Mode (MGM)", 2021, 1085 . 1087 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1088 Requirement Levels", BCP 14, RFC 2119, 1089 DOI 10.17487/RFC2119, March 1997, 1090 . 1092 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 1093 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 1094 2013, . 1096 [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: 1097 Digital Signature Algorithm", RFC 7091, 1098 DOI 10.17487/RFC7091, December 2013, 1099 . 1101 [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher 1102 "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, 1103 . 1105 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 1106 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 1107 on the Cryptographic Algorithms to Accompany the Usage of 1108 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 1109 RFC 7836, DOI 10.17487/RFC7836, March 2016, 1110 . 1112 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1113 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1114 May 2017, . 1116 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1117 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1118 . 1120 [RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric 1121 Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, 1122 . 1124 10.2. Informative References 1126 [AASS19] Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A. 1127 Sokolov, "Continuing to reflect on TLS 1.3 with external 1128 PSK", Cryptology ePrint Archive Report 2019/421, April 1129 2019, . 1131 [GOST3410-2012] 1132 Federal Agency on Technical Regulating and Metrology, 1133 "Information technology. Cryptographic data security. 1134 Signature and verification processes of [electronic] 1135 digital signature", GOST R 34.10-2012, 2012. 1137 [GOST3411-2012] 1138 Federal Agency on Technical Regulating and Metrology, 1139 "Information technology. Cryptographic Data Security. 1140 Hashing function", GOST R 34.11-2012, 2012. 1142 [GOST3412-2015] 1143 Federal Agency on Technical Regulating and Metrology, 1144 "Information technology. Cryptographic data security. 1145 Block ciphers", GOST R 34.12-2015, 2015. 1147 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 1148 with PSK", Cryptology ePrint Archive Report 2019/347, 1149 April 2019, . 1151 Appendix A. Test Examples 1153 TODO 1155 Appendix B. Contributors 1157 o Lilia Akhmetzyanova 1158 CryptoPro 1159 lah@cryptopro.ru 1161 o Alexandr Sokolov 1162 CryptoPro 1163 sokolov@cryptopro.ru 1165 o Vasily Nikolaev 1166 CryptoPro 1167 nikolaev@cryptopro.ru 1169 o Lidia Nikiforova 1170 CryptoPro 1171 nikiforova@cryptopro.ru 1173 Appendix C. Acknowledgments 1175 Authors' Addresses 1177 Stanislav Smyshlyaev (editor) 1178 CryptoPro 1179 18, Suschevsky val 1180 Moscow 127018 1181 Russian Federation 1183 Phone: +7 (495) 995-48-20 1184 Email: svs@cryptopro.ru 1185 Evgeny Alekseev 1186 CryptoPro 1187 18, Suschevsky val 1188 Moscow 127018 1189 Russian Federation 1191 Email: alekseev@cryptopro.ru 1193 Ekaterina Griboedova 1194 CryptoPro 1195 18, Suschevsky val 1196 Moscow 127018 1197 Russian Federation 1199 Email: griboedova.e.s@gmail.com 1201 Alexandra Babueva 1202 CryptoPro 1203 18, Suschevsky val 1204 Moscow 127018 1205 Russian Federation 1207 Email: babueva@cryptopro.ru