idnits 2.17.1 draft-smyshlyaev-tls13-gost-suites-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2020) is 1223 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. Griboedova 5 Expires: June 17, 2021 A. Babueva 6 CryptoPro 7 December 14, 2020 9 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 10 1.3 11 draft-smyshlyaev-tls13-gost-suites-03 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. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 17, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 60 3. Basic Terms and Definitions . . . . . . . . . . . . . . . . . 4 61 4. Cipher Suite Definition . . . . . . . . . . . . . . . . . . . 6 62 4.1. Record Protection Algorithm . . . . . . . . . . . . . . . 6 63 4.1.1. AEAD Algorithm . . . . . . . . . . . . . . . . . . . 7 64 4.1.2. TLSTREE . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1.3. SNMAX parameter . . . . . . . . . . . . . . . . . . . 10 66 4.2. Hash Algorithm . . . . . . . . . . . . . . . . . . . . . 10 67 5. Signature Scheme Definition . . . . . . . . . . . . . . . . . 11 68 5.1. Signature Algorithm . . . . . . . . . . . . . . . . . . . 11 69 5.2. Elliptic Curve . . . . . . . . . . . . . . . . . . . . . 12 70 5.3. SIGN function . . . . . . . . . . . . . . . . . . . . . . 13 71 6. Key Exchange and Authentication . . . . . . . . . . . . . . . 13 72 6.1. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 14 73 6.1.1. ECDHE Shared Secret Calculation . . . . . . . . . . . 14 74 6.1.1.1. ECDHE Shared Secret Calculation on Client Side . 14 75 6.1.1.2. ECDHE Shared Secret Calculation on Server Side . 16 76 6.1.1.3. Public ephemeral key representation . . . . . . . 17 77 6.1.2. Values for the TLS Supported Groups Registry . . . . 17 78 6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 18 79 6.3. Handshake Messages . . . . . . . . . . . . . . . . . . . 19 80 6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 19 81 6.3.2. CertificateRequest . . . . . . . . . . . . . . . . . 20 82 6.3.3. Certificate . . . . . . . . . . . . . . . . . . . . . 21 83 6.3.4. CertificateVerify . . . . . . . . . . . . . . . . . . 21 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 8. Historical considerations . . . . . . . . . . . . . . . . . . 24 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 89 10.2. Informative References . . . . . . . . . . . . . . . . . 26 90 Appendix A. Test Examples . . . . . . . . . . . . . . . . . . . 27 91 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 27 92 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 27 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 95 1. Introduction 97 This document defines four new cipher suites (the TLS13_GOST cipher 98 suites) and seven new signature schemes (the TLS13_GOST signature 99 schemes) for the Transport Layer Security (TLS) Protocol Version 1.3, 100 that are based on Russian cryptographic standards GOST R 34.12-2015 101 [GOST3412-2015] (the English version can be found in [RFC7801]), GOST 102 R 34.11-2012 [GOST3411-2012] (the English version can be found in 103 [RFC6986]) and GOST R 34.10-2012 [GOST3410-2012] (the English version 104 can be found in [RFC7091]). 106 The TLS13_GOST cipher suites (see Section 4) have the following 107 values: 109 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}; 110 TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04}; 111 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05}; 112 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}. 114 Each TLS13_GOST cipher suite specifies a pair (record protection 115 algorithm, hash algorithm) such that: 117 o The record protection algorithm is the AEAD algorithm (see 118 Section 4.1.1) based on the GOST R 34.12-2015 block cipher 119 [RFC7801] in the Multilinear Galois Mode (MGM) [DraftMGM] and the 120 external re-keying approach (see [RFC8645]) intended for 121 increasing the lifetime of symmetric keys used to protect records. 123 o The hash algorithm is the GOST R 34.11-2012 algorithm [RFC6986]. 125 Note: The TLS13_GOST cipher suites are divided into two types 126 (depending on the key lifetime limitations, see Section 4.1.2 and 127 Section 4.1.3): the "_S" (strong) cipher suites and the "_L" (light) 128 cipher suites. 130 The TLS13_GOST signature schemes that can be used with the TLS13_GOST 131 cipher suites have the following values: 133 gostr34102012_256a = 0x0709; 135 gostr34102012_256b = 0x070A; 137 gostr34102012_256c = 0x070B; 139 gostr34102012_256d = 0x070C; 141 gostr34102012_512a = 0x070D; 142 gostr34102012_512b = 0x070E; 144 gostr34102012_512c = 0x070F. 146 Each TLS13_GOST signature scheme specifies a pair (signature 147 algorithm, elliptic curve) such that: 149 o The signature algorithm is the GOST R 34.10-2012 algorithm 150 [RFC7091]. 152 o The elliptic curve is one of the curves defined in Section 5.2. 154 Additionally, this document specifies the key exchange and 155 authentication process in case of negotiating TLS13_GOST cipher 156 suites (see Section 6). 158 2. Conventions Used in This Document 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 3. Basic Terms and Definitions 168 This document uses the following terms and definitions for the sets 169 and operations on the elements of these sets: 171 B_t the set of byte strings of length t, t >= 0, for t = 172 0 the B_t set consists of a single empty string of 173 zero length. If A is an element of B_t, then A = 174 (a_1, a_2, ... , a_t), where a_1, a_2, ... , a_t are 175 in {0, ... , 255}; 177 B* the set of all byte strings of a finite length 178 (hereinafter referred to as strings), including the 179 empty string; 181 A[i..j] the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in 182 B_{j-i+1}, where A = (a_1, a_2, ... , a_t) in B_t and 183 1<=i<=j<=t; 185 |A| the byte length of the string A; 187 A | C the concatenation of strings A and C both belonging 188 to B*, i.e., a string in B_{|A|+|C|}, where the left 189 substring in B_|A| is equal to A, and the right 190 substring in B_|C| is equal to C; 192 i & j bitwise AND of integers i and j; 194 STR_t the byte string STR_t(i) = (i_1, ... , i_t) in B_t 195 corresponding to an integer i = 256^{t-1} * i_1 + ... 196 + 256 * i_{t-1} + i_t (the interpretation of the 197 integer as a byte string in big-endian format); 199 str_t the byte string str_t(i) = (i_1, ... , i_t) in B_t 200 corresponding to an integer i = 256^{t-1} * i_t + ... 201 + 256 * i_2 + i_1 (the interpretation of the integer 202 as a byte string in little-endian format); 204 k the byte-length of the block cipher key; 206 n the byte-length of the block cipher block; 208 IVlen the byte-length of the initialization vector; 210 S the byte-length of the authentication tag; 212 E_i the elliptic curve indicated by client in 213 "supported_groups" extension; 215 O_i the zero point of the elliptic curve E_i; 217 m_i the order of group of points belonging to the 218 elliptic curve E_i; 220 q_i the cyclic subgroup order of group of points 221 belonging to the elliptic curve E_i; 223 h_i the cyclic subgroup cofactor which is equal to m_i / 224 q_i; 226 Q_sign the public key stored in endpoint's certificate; 228 d_sign the private key that corresponds to the Q_sign key; 230 P_i the point of the elliptic curve E_i of the order q_i; 232 (d_C^i, Q_C^i) the client's ephemeral key pair which consists of the 233 private key and the public key corresponding to the 234 elliptic curve E_i; 236 (d_S^i, Q_S^i) the server's ephemeral key pair which consists of the 237 private key and the public key corresponding to the 238 elliptic curve E_i. 240 4. Cipher Suite Definition 242 The cipher suite value is used to indicate a record protection 243 algorithm and a hash algorithm which an endpoint supports (see 244 Section 4.1.2 of [RFC8446]). 246 This section defines the following four TLS13_GOST cipher suites that 247 can be used to support Russian cryptographic algorithms: 249 CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}; 250 CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04}; 251 CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05}; 252 CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}; 254 Each cipher suite specifies a pair of the record protection algorithm 255 (see Section 4.1) and the hash algorithm (Section 4.2). 257 4.1. Record Protection Algorithm 259 In accordance with Section 5.2 of [RFC8446] the record protection 260 algorithm translates a TLSPlaintext structure into a TLSCiphertext 261 structure. If TLS13_GOST cipher suite is negotiated, the 262 encrypted_record field of the TLSCiphertext structure MUST be set to 263 the AEADEncrypted value computed as follows: 265 AEADEncrypted = AEAD-Encrypt(sender_record_write_key, nonce, 266 associated_data, plaintext), 268 where 270 o the AEAD-Encrypt function is defined in Section 4.1.1; 272 o the sender_record_write_key is derived from the sender_write_key 273 (see Section 7.3 of [RFC8446]) using TLSTREE function defined in 274 Section 4.1.2 and sequence number seqnum as follows: 276 sender_record_write_key = TLSTREE(sender_write_key, seqnum); 278 o the nonce value is derived from the record sequence number seqnum 279 and the sender_write_iv value (see Section 7.3 of [RFC8446]) in 280 accordance with Section 5.3 of [RFC8446]; 282 o the associated_data value is the record header that is generated 283 in accordance with Section 5.2 of [RFC8446]; 285 o the plaintext value is the TLSInnerPlaintext structure encoded in 286 accordance with Section 5.2 of [RFC8446]. 288 Note1: The AEAD-Encrypt function is exactly the same as the AEAD- 289 Encrypt function defined in [RFC8446] except the key (the first 290 argument) is calculated from the sender_write_key and sequence number 291 seqnum for each message separately to support external re-keying 292 approach according to [RFC8645]. 294 Note2: The record sequence number is the value in the range 0-SNMAX, 295 where the SNMAX value is defined in Section 4.1.3. The SNMAX 296 parameter is specified by the particular TLS13_GOST cipher suite to 297 limit the amount of data that can be encrypted under the same traffic 298 key material (sender_write_key, sender_write_iv). 300 The record deprotection algorithm reverses the process of the record 301 protection. In order to decrypt and verify the protected record with 302 sequence number seqnum the algorithm takes as input the 303 sender_record_write_key is derived from the sender_write_key, nonce, 304 associated_data and the AEADEncrypted value and outputs the res value 305 which is either the plaintext or an error indicating that the 306 decryption failed. If TLS13_GOST cipher suite is negotiated, the res 307 value MUST be computed as follows: 309 res = AEAD-Decrypt(sender_record_write_key, nonce, 310 associated_data, AEADEncrypted), 312 where the AEAD-Decrypt function is defined in Section 4.1.1. 314 Note: The AEAD-Decrypt function is exactly the same as the AEAD- 315 Decrypt function defined in [RFC8446] except the key (the first 316 argument) is calculated from the sender_write_key and sequence number 317 seqnum for each message separately to support external re-keying 318 approach according to [RFC8645]. 320 4.1.1. AEAD Algorithm 322 The AEAD-Encrypt and AEAD-Decrypt functions are defined as follows. 324 +-------------------------------------------------------------------+ 325 | AEAD-Encrypt(K, nonce, A, P) | 326 |-------------------------------------------------------------------| 327 | Input: | 328 | - encryption key K in B_k, | 329 | - unique vector nonce in B_IVlen, | 330 | - associated authenticated data A in B_r, r >= 0, | 331 | - plaintext P in B_t, t >= 0. | 332 | Output: | 333 | - ciphertext C in B_{|P|}, | 334 | - authentication tag T in B_S. | 335 |-------------------------------------------------------------------| 336 | 1. MGMnonce = nonce[1..1] & 0x7f | nonce[2..IVlen]; | 337 | 2. (MGMnonce, A, C, T) = MGM-Encrypt(K, MGMnonce, A, P); | 338 | 3. Return C | T. | 339 +-------------------------------------------------------------------+ 341 +-------------------------------------------------------------------+ 342 | AEAD-Decrypt(K, nonce, A, C | T) | 343 |-------------------------------------------------------------------| 344 | Input: | 345 | - encryption key K in B_k, | 346 | - unique vector nonce in B_IVlen, | 347 | - associated authenticated data A in B_r, r >= 0, | 348 | - ciphertext C in B_t, t >= 0, | 349 | - authentication tag T in B_S. | 350 | Output: | 351 | - plaintext P in B_{|C|} or FAIL. | 352 |-------------------------------------------------------------------| 353 | 1. MGMnonce = nonce[1..1] & 0x7f | nonce[2..IVlen]; | 354 | 2. res' = MGM-Decrypt(K, MGMnonce, A, C, T); | 355 | 3. IF res' = FAIL then return FAIL; | 356 | 4. IF res' = (A, P) then return P. | 357 +-------------------------------------------------------------------+ 359 where 361 o MGM-Encrypt and MGM-Decrypt functions are defined in [DraftMGM]. 362 The size of the authentication tag T is equal to n bytes (S = n). 363 The size of the nonce parameter is equal to n bytes (IVlen = n). 365 The cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and 366 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik 367 [RFC7801] as a base block cipher for the AEAD algorithm. The block 368 length n is 16 bytes (n = 16) and the key length k is 32 bytes (k = 369 32). 371 The cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and 372 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST use Magma [GOST3412-2015] 373 as a base block cipher for the AEAD algorithm. The block length n is 374 8 bytes (n = 8) and the key length k is 32 bytes (k = 32). 376 4.1.2. TLSTREE 378 The TLS13_GOST cipher suites use the TLSTREE function for the 379 external re-keying approach (see [RFC8645]). The TLSTREE function is 380 defined as follows: 382 TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8(i & C_1)), 383 STR_8(i & C_2)), STR_8(i & C_3)), 385 where 387 o K_root in B_32; 389 o i in {0, 1, ... , 2^64 - 1}; 391 o KDF_j(K, D), j = 1, 2, 3, is the key derivation function defined 392 as follows: 394 KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D), 395 KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D), 396 KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D), 398 where the KDF_GOSTR3411_2012_256 function is defined in [RFC7836], 399 K in B_32, D in B_8. 401 o C_1, C_2, C_3 are constants defined by the particular cipher suite 402 as follows: 404 +------------------------------------------+----------------------+ 405 | CipherSuites | C_1, C_2, C_3 | 406 +------------------------------------------+----------------------+ 407 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L |C_1=0xf800000000000000| 408 | |C_2=0xfffffff000000000| 409 | |C_3=0xffffffffffffe000| 410 +------------------------------------------+----------------------+ 411 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L |C_1=0xffe0000000000000| 412 | |C_2=0xffffffffc0000000| 413 | |C_3=0xffffffffffffff80| 414 +------------------------------------------+----------------------+ 415 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S |C_1=0xffffffffe0000000| 416 | |C_2=0xffffffffffff0000| 417 | |C_3=0xfffffffffffffff8| 418 +------------------------------------------+----------------------+ 419 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S |C_1=0xfffffffffc000000| 420 | |C_2=0xffffffffffffe000| 421 | |C_3=0xffffffffffffffff| 422 +------------------------------------------+----------------------+ 423 Table 1 425 4.1.3. SNMAX parameter 427 The SNMAX parameter is the maximum number of records encrypted under 428 the same traffic key material (sender_write_key and sender_write_iv) 429 and is defined by the particular cipher suite as follows: 431 +------------------------------------------+--------------------+ 432 | CipherSuites | SNMAX | 433 +------------------------------------------+--------------------+ 434 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L | SNMAX = 2^64 - 1 | 435 +------------------------------------------+--------------------+ 436 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L | SNMAX = 2^64 - 1 | 437 +------------------------------------------+--------------------+ 438 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S | SNMAX = 2^42 - 1 | 439 +------------------------------------------+--------------------+ 440 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | SNMAX = 2^39 - 1 | 441 +------------------------------------------+--------------------+ 442 Table 2 444 4.2. Hash Algorithm 446 The Hash algorithm is used for key derivation process (see 447 Section 7.1 of [RFC8446]), Finished message calculation (see 448 Section 4.4.4 of [RFC8446]), Transcript-Hash function computation 449 (see Section 4.4.1 of [RFC8446]), PSK binder value calculation (see 450 Section 4.2.11.2 of [RFC8446]), external re-keying approach (see 451 Section 4.1.2) and other purposes. 453 In case of negotiating a TLS13_GOST cipher suite the Hash algorithm 454 MUST be the GOST R 34.11-2012 [RFC6986] hash algorithm with 32-byte 455 (256-bit) hash value. 457 5. Signature Scheme Definition 459 The signature scheme value is used to indicate a single signature 460 algorithm and a curve that can be used in digital signature (see 461 Section 4.2.3 of [RFC8446]). 463 This section defines the following seven TLS13_GOST signature schemes 464 that can be used to support Russian cryptographic algorithms: 466 enum { 467 gostr34102012_256a(0x0709), 468 gostr34102012_256b(0x070A), 469 gostr34102012_256c(0x070B), 470 gostr34102012_256d(0x070C), 471 gostr34102012_512a(0x070D), 472 gostr34102012_512b(0x070E), 473 gostr34102012_512c(0x070F) 474 } SignatureScheme; 476 If TLS13_GOST cipher suite is negotiated and authentication via 477 certificates is required one of the TLS13_GOST signature schemes 478 listed above SHOULD be used. 480 Each signature scheme specifies a pair of the signature algorithm 481 (see Section 5.1) and the elliptic curve (see Section 5.2). 483 5.1. Signature Algorithm 485 Signature algorithms corresponding to the TLS13_GOST signature 486 schemes are defined as follows: 488 +------------------+--------------------------------------+--------+ 489 | SignatureScheme | Signature Algorithm | Refe- | 490 | Value | | rences | 491 +------------------+--------------------------------------+--------+ 492 |gostr34102012_256a|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 493 +------------------+--------------------------------------+--------+ 494 |gostr34102012_256b|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 495 +------------------+--------------------------------------+--------+ 496 |gostr34102012_256c|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 497 +------------------+--------------------------------------+--------+ 498 |gostr34102012_256d|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 499 +------------------+--------------------------------------+--------+ 500 |gostr34102012_512a|GOST R 34.10-2012 , 64-byte key length|RFC 7091| 501 +------------------+--------------------------------------+--------+ 502 |gostr34102012_512b|GOST R 34.10-2012 , 64-byte key length|RFC 7091| 503 +------------------+--------------------------------------+--------+ 504 |gostr34102012_512c|GOST R 34.10-2012 , 64-byte key length|RFC 7091| 505 +------------------+--------------------------------------+--------+ 506 Table 3 508 5.2. Elliptic Curve 510 Elliptic curves corresponding to the TLS13_GOST signature schemes are 511 defined as follows: 513 +------------------+--------------------------------------+--------+ 514 | SignatureScheme | Curve Identifier Value | Refe- | 515 | Value | | rences | 516 +------------------+--------------------------------------+--------+ 517 |gostr34102012_256a| id-tc26-gost-3410-2012-256-paramSetA |RFC 7836| 518 +------------------+--------------------------------------+--------+ 519 |gostr34102012_256b|id-GostR3410-2001-CryptoPro-A-ParamSet|RFC 4357| 520 +------------------+--------------------------------------+--------+ 521 |gostr34102012_256c|id-GostR3410-2001-CryptoPro-B-ParamSet|RFC 4357| 522 +------------------+--------------------------------------+--------+ 523 |gostr34102012_256d|id-GostR3410-2001-CryptoPro-C-ParamSet|RFC 4357| 524 +------------------+--------------------------------------+--------+ 525 |gostr34102012_512a| id-tc26-gost-3410-12-512-paramSetA |RFC 7836| 526 +------------------+--------------------------------------+--------+ 527 |gostr34102012_512b| id-tc26-gost-3410-12-512-paramSetB |RFC 7836| 528 +------------------+--------------------------------------+--------+ 529 |gostr34102012_512c| id-tc26-gost-3410-2012-512-paramSetC |RFC 7836| 530 +------------------+--------------------------------------+--------+ 531 Table 4 533 5.3. SIGN function 535 If TLS13_GOST signature scheme is used, the signature value in 536 CertificateVerify message (see Section 6.3.4) MUST be calculated 537 using the SIGN function defined as follows: 539 +-----------------------------------------------------+ 540 | SIGN(d_sign, M) | 541 |-----------------------------------------------------| 542 | Input: | 543 | - the sign key d_sign: 0 < d_sign < q; | 544 | - the byte string M in B*. | 545 | Output: | 546 | - signature value sgn in B_{2*l}. | 547 |-----------------------------------------------------| 548 | 1. (r, s) = SIGNGOST(d_sign, M) | 549 | 2. Return str_l(r) | str_l(s). | 550 |-----------------------------------------------------+ 552 where 554 o q is the subgroup order of group of points of the elliptic curve; 556 o l is defined as follows: 558 * l = 32 for gostr34102012_256a, gostr34102012_256b, 559 gostr34102012_256c and gostr34102012_256d signature schemes; 561 * l = 64 for gostr34102012_512a, gostr34102012_512b and 562 gostr34102012_512c signature schemes; 564 o SIGNGOST is an algorithm which takes as an input private key 565 d_sign and message M and returns a pair of integers (r, s) 566 calculated during signature generation process in accordance with 567 the GOST R 34.10-2012 signature algorithm (see Section 6.1 of 568 [RFC7091]). 570 Note: The signature value sgn is the concatenation of two strings 571 that are byte representations of r and s values in the little-endian 572 format. 574 6. Key Exchange and Authentication 576 Key exchange and authentication process in case of using TLS13_GOST 577 cipher suites is defined in Section 6.1, Section 6.2 and Section 6.3. 579 6.1. Key Exchange 581 TLS13_GOST cipher suites support three basic key exchange modes which 582 are defined in [RFC8446]: ECDHE, PSK-only and PSK-with-ECDHE. 584 Note: In accordance with [RFC8446] TLS 1.3 also supports key exchange 585 modes based on Diffie-Hellman protocol over finite fields. However, 586 TLS13_GOST cipher suites MUST use only modes based on Diffie-Hellman 587 protocol over elliptic curves. 589 In accordance with [RFC8446] PSKs can be divided into two types: 591 o internal PSKs which can be established during the previous 592 connection; 594 o external PSKs which can be established out of band. 596 If TLS13_GOST cipher suite is negotiated, PSK-only key exchange mode 597 SHOULD be established only via the internal PSKs, and external PSKs 598 SHOULD be used only in PSK-with-ECDHE mode (see more in Section 9). 600 If TLS13_GOST cipher suite is negotiated and ECDHE or PSK-with-ECDHE 601 key exchange mode is used the ECDHE shared secret value should be 602 calculated in accordance with Section 6.1.1 on the basis of one of 603 the elliptic curves defined in Section 6.1.2. 605 6.1.1. ECDHE Shared Secret Calculation 607 If TLS13_GOST cipher suite is negotiated, ECDHE shared secret value 608 should be calculated in accordance with Section 6.1.1.1 and 609 Section 6.1.1.2. The public ephemeral keys used to obtain ECDHE 610 shared secret value should be represented in format described in 611 Section 6.1.1.3. 613 6.1.1.1. ECDHE Shared Secret Calculation on Client Side 615 The client calculates ECDHE shared secret value in accordance with 616 the following steps: 618 1. Chooses from all supported curves E_1, ..., E_R the set of curves 619 E_{i_1}, ..., E_{i_r}, 1 <= i_1 <= i_r <= R, where 621 o r >= 1 in the case of the first ClientHello message; 623 o r = 1 in the case of responding to HelloRetryRequest message, 624 E_{i_1} corresponds to the curve indicated in the "key_share" 625 extension in the HelloRetryRequest message. 627 2. Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ..., 628 (d_C^{i_r}, Q_C^{i_r}) corresponding to the curves E_{i_1}, ..., 629 E_{i_r}, where for each i in {i_1, ..., i_r}: 631 o d_C^i is chosen from {1, ..., q_i - 1} at random; 633 o Q_C^i = d_C^i * P_i. 635 3. Sends ClientHello message specified in accordance with 636 Section 4.1.2 of [RFC8446] and Section 6.3.1, which contains: 638 o "key_share" extension with public ephemeral keys Q_C^{i_1}, ..., 639 Q_C^{i_r} generated in accordance with Section 4.2.8 of [RFC8446]; 641 o "supported_groups" extension with supported curves E_1, ..., E_R 642 generated in accordance with Section 4.2.7 of [RFC8446]. 644 Note: Client MAY send an empty "key_share" extension in the first 645 ClientHello in order to request group selection from the server in 646 the HelloRetryRequest message and to generate ephemeral key for the 647 selected group only. The ECDHE value may be calculated without 648 sending HelloRetryRequest, if the "key_share" extension in the first 649 ClientHello message consists the value corresponded to the curve that 650 will be selected by the server. 652 4. In case of receiving HelloRetryRequest message client MUST return 653 to step 1 and correct parameters in accordance with Section 4.1.2 of 654 [RFC8446]. In case of receiving ServerHello message client proceeds 655 to the next step. In other cases client MUST terminate the 656 connection with "unexpected_message" alert. 658 5. Extracts curve E_res and ephemeral key Q_S^res, res in {1, ..., 659 R}, from ServerHello message and checks whether the Q_S^res belongs 660 to E_res. If this check fails, the client MUST abort the handshake 661 with "handshake_failure" alert. 663 6. Generates Q^ECDHE: 665 Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) * Q_S^res. 667 7. Client MUST check whether the computed shared secret Q^ECDHE is 668 not equal to the zero point O_res. If this check fails, the client 669 MUST abort the handshake with "handshake_failure" alert. 671 8. Shared secret value ECDHE is the byte representation of the 672 coordinate X^ECDHE of point Q^ECDHE in the little-endian format: 674 ECDHE = str_{coordinate_length}(X^ECDHE), 676 where the coordinate_length value is defined by the particular 677 elliptic curve (see Section 6.1.2). 679 6.1.1.2. ECDHE Shared Secret Calculation on Server Side 681 Upon receiving the ClientHello message, the server calculates ECDHE 682 shared secret value in accordance with the following steps: 684 1. Chooses the curve E_res, res in {1, ..., R}, from the list of the 685 curves E_1, ..., E_R indicated in "supported_groups" extension in 686 ClientHello message and the corresponding public ephemeral key value 687 Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r}, 1 <= i_1 <= i_r <= 688 R, indicated in "key_share" extension. If no corresponding public 689 ephemeral key value is found (res in {1, ..., R}\{i_1, ..., i_r}), 690 server MUST send HelloRetryRequest message with "key_share" extension 691 indicating the selected elliptic curve E_res and wait for the new 692 ClientHello message. 694 2. Checks whether Q_C^res belongs to E_res. If this check fails, 695 the server MUST abort the handshake with "handshake_failure" alert. 697 3. Generates ephemeral key pair (d_S^res, Q_S^res) corresponding to 698 E_res: 700 o d_S^res is chosen from {1, ..., q_res - 1} at random; 702 o Q_S^res = d_S^res * P_res. 704 4. Sends ServerHello message generated in accordance with 705 Section 4.1.3 of [RFC8446] and Section 6.3.1 with "key_share" 706 extension which contains public ephemeral key value Q_S^res 707 corresponding to E_res. 709 5. Generates Q^ECDHE: 711 Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res. 713 6. Server MUST check whether the computed shared secret Q^ECDHE is 714 not equal to the zero point O_res. If this check fails, the server 715 MUST abort the handshake with "handshake_failure" alert. 717 7. Shared secret value ECDHE is the byte representation of the 718 coordinate X^ECDHE of point Q^ECDHE in the little-endian format: 720 ECDHE = str_{coordinate_length}(X^ECDHE), 722 where the coordinate_length value is defined by the particular 723 elliptic curve (see Section 6.1.2). 725 6.1.1.3. Public ephemeral key representation 727 This section defines the representation format of the public 728 ephemeral keys generated during ECDHE shared secret calculation (see 729 Section 6.1.1.1 and Section 6.1.1.2). 731 If TLS13_GOST cipher suite is negotiated and ECDHE or PSK-with-ECDHE 732 key exchange mode is used, the public ephemeral key Q indicated in 733 the KeyShareEntry.key_exchange field MUST contain the data defined by 734 the following structure: 736 struct { 737 opaque X[coordinate_length]; 738 opaque Y[coordinate_length]; 739 } PlainPointRepresentation; 741 where X and Y, respectively, contain the byte representations of the 742 x and the y values of point Q (Q = (x, y)) in the little-endian 743 format and are specified as follows: 745 X = str_{coordinate_length}(x); 747 Y = str_{coordinate_length}(y). 749 The coordinate_length value is defined by the particular elliptic 750 curve (see Section 6.1.2). 752 6.1.2. Values for the TLS Supported Groups Registry 754 The "supported_groups" extension is used to indicate the set of the 755 elliptic curves supported by an endpoint and is defined in 756 Section 4.2.7 [RFC8446]. This extension is always contained in 757 ClientHello message and optionally in EncryptedExtensions message. 759 This section defines the following seven elliptic curves that can be 760 used to support Russian cryptographic algorithms: 762 enum { 763 GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25), 764 GC512A(0x26), GC512B(0x27), GC512C(0x28) 765 } NamedGroup; 766 If TLS13_GOST cipher suite is negotiated and ECDHE or PSK-with-ECDHE 767 key exchange mode is established, one of the elliptic curves listed 768 above SHOULD be used. 770 Each curve corresponds to the particular identifier and specifies the 771 value of coordinate_length parameter (see "cl" column) as follows: 773 +-----------+--------------------------------------+----+---------+ 774 |Description| Curve Identifier Value | cl |Reference| 775 +-----------+--------------------------------------+----+---------+ 776 | GC256A | id-tc26-gost-3410-2012-256-paramSetA | 32 | RFC 7836| 777 +-----------+--------------------------------------+----+---------+ 778 | GC256B |id-GostR3410-2001-CryptoPro-A-ParamSet| 32 | RFC 4357| 779 +-----------+--------------------------------------+----+---------+ 780 | GC256C |id-GostR3410-2001-CryptoPro-B-ParamSet| 32 | RFC 4357| 781 +-----------+--------------------------------------+----+---------+ 782 | GC256D |id-GostR3410-2001-CryptoPro-C-ParamSet| 32 | RFC 4357| 783 +-----------+--------------------------------------+----+---------+ 784 | GC512A | id-tc26-gost-3410-12-512-paramSetA | 64 | RFC 7836| 785 +-----------+--------------------------------------+----+---------+ 786 | GC512B | id-tc26-gost-3410-12-512-paramSetB | 64 | RFC 7836| 787 +-----------+--------------------------------------+----+---------+ 788 | GC512C | id-tc26-gost-3410-2012-512-paramSetC | 64 | RFC 7836| 789 +-----------+--------------------------------------+----+---------+ 790 Table 5 792 Note: The identifier values and the corresponding elliptic curves are 793 the same as in [DraftGostTLS12]. 795 6.2. Authentication 797 In accordance with [RFC8446] authentication can happen via signature 798 with certificate or via symmetric pre-shared key (PSK). The server 799 side of the channel is always authenticated; the client side is 800 optionally authenticated. 802 PSK-based authentication happens as a side effect of key exchange. 803 If TLS13_GOST cipher suite is negotiated, external PSKs SHOULD be 804 combined only with the mutual authentication (see more in Section 9). 806 Certificate-based authentication happens via Authentication messages 807 and optional CertificateRequest message (sent if client 808 authentication is required). In case of negotiating TLS13_GOST 809 cipher suites the signature schemes used for certificate-based 810 authentication are defined in Section 5 and the Authentication 811 messages are specified in Section 6.3.3 and Section 6.3.4. The 812 CertificateRequest message is specified in Section 6.3.2. 814 6.3. Handshake Messages 816 The TLS13_GOST cipher suites specify the ClientHello, ServerHello, 817 CertificateRequest, Certificate and CertificateVerify handshake 818 messages that are described in further detail below. 820 6.3.1. Hello Messages 822 The ClientHello message is sent when a client first connects to a 823 server or responds to a HelloRetryRequest message and is specified in 824 accordance with [RFC8446] as follows. 826 struct { 827 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 828 Random random; 829 opaque legacy_session_id<0..32>; 830 CipherSuite cipher_suites<2..2^16-2>; 831 opaque legacy_compression_methods<1..2^8-1>; 832 Extension extensions<8..2^16-1>; 833 } ClientHello; 835 In order to negotiate a TLS13_GOST cipher suite, the ClientHello 836 message MUST meet the following requirements. 838 o The ClientHello.cipher_suites field MUST contain the values 839 defined in Section 4. 841 o If server authentication via a certificate is required, the 842 extension_data field of the "signature_algorithms" extension MUST 843 contain the values defined in Section 5, which correspond to the 844 GOST R 34.10-2012 signature algorithm. 846 o If server authentication via a certificate is required and the 847 client uses optional "signature_algorithms_cert" extension, the 848 extension_data field of this extension SHOULD contain the values 849 defined in Section 5, which correspond to the GOST R 34.10-2012 850 signature algorithm. 852 o If client wants to establish TLS 1.3 connection using ECDHE shared 853 secret value, the extension_data field of the "supported_groups" 854 extension MUST contain the elliptic curve identifiers defined in 855 Section 6.1.2. 857 The ServerHello message is sent by the server in response to a 858 ClientHello message to negotiate an acceptable set of handshake 859 parameters based on the ClientHello and is specified in accordance 860 with [RFC8446] as follows. 862 struct { 863 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 864 Random random; 865 opaque legacy_session_id_echo<0..32>; 866 CipherSuite cipher_suite; 867 uint8 legacy_compression_method = 0; 868 Extension extensions<6..2^16-1>; 869 } ServerHello; 871 In case of negotiating a TLS13_GOST cipher suite, the ServerHello 872 message MUST meet the following requirements. 874 o The ServerHello.cipher_suite field MUST contain one of the values 875 defined in Section 4. 877 o If server decides to establish TLS 1.3 connection using ECDHE 878 shared secret value, the extension_data field of the "key_share" 879 extension MUST contain the elliptic curve identifier and the 880 public ephemeral key that satisfy the following conditions. 882 * The elliptic curve identifier corresponds to a value that was 883 provided in the "supported_groups" and the "key_share" 884 extensions in the ClientHello message. 886 * The elliptic curve identifier is one of the values defined in 887 Section 6.1.2. 889 * The public ephemeral key corresponds to the elliptic curve 890 specified by the KeyShareEntry.group identifier. 892 6.3.2. CertificateRequest 894 This message is sent when server requests client authentication via a 895 certificate and is specified in accordance with [RFC8446] as follows. 897 struct { 898 opaque certificate_request_context<0..2^8-1>; 899 Extension extensions<2..2^16-1>; 900 } CertificateRequest; 901 If TLS13_GOST cipher suite is negotiated, the CertificateRequest 902 message MUST meet the following requirements. 904 o The extension_data field of the "signature_algorithms" extension 905 MUST contain only the values defined in Section 5. 907 o If server uses optional "signature_algorithms_cert" extension, the 908 extension_data field of this extension SHOULD contain only the 909 values defined in Section 5. 911 6.3.3. Certificate 913 This message is sent to convey the endpoint's certificate chain to 914 the peer and is specified in accordance with [RFC8446] as follows. 916 struct { 917 opaque certificate_request_context<0..2^8-1>; 918 CertificateEntry certificate_list<0..2^24-1>; 919 } Certificate; 921 If TLS13_GOST cipher suite is negotiated, the Certificate message 922 MUST meet the following requirements. 924 o Each endpoint's certificate provided to the peer MUST be signed 925 using the algorithm which corresponds to a signature scheme 926 indicated by the peer in its "signature_algoritms_cert" extension, 927 if present (or in the "signature_algorithms" extension, 928 otherwise). 930 o The signature algorithm used for signing certificates SHOULD 931 correspond to the one of the signature schemes defined in 932 Section 5. 934 6.3.4. CertificateVerify 936 This message is sent to provide explicit proof that an endpoint 937 possesses the private key corresponding to the public key indicated 938 in its certificate and is specified in accordance with [RFC8446] as 939 follows. 941 struct { 942 SignatureScheme algorithm; 943 opaque signature<0..2^16-1>; 944 } CertificateVerify; 945 If TLS13_GOST cipher suite is negotiated, the CertificateVerify 946 message MUST meet the following requirements. 948 o The CertificateVerify.algorithm field MUST contain the signature 949 scheme identifier which corresponds to the value indicated in the 950 peer's "signature_algorithms" extension and which is one of the 951 values defined in Section 5. 953 o The CertificateVerify.signature field contains the sgn value, 954 which is computed as follows: 956 sgn = SIGN(d_sign, M), 958 o where 960 * the SIGN function is defined in Section 5, 962 * d_sign is the sender long-term private key that corresponds to 963 the sender long-term public key Q_sign from the sender's 964 certificate, 966 * the message M is defined in accordance with Section 4.4.3 of 967 [RFC8446]. 969 7. IANA Considerations 971 IANA has added numbers {0xC1, 0x03}, {0xC1, 0x04}, {0xC1, 0x05} and 972 {0xC1, 0x06} with the names 973 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L, 974 TLS_GOSTR341112_256_WITH_MAGMA_MGM_L, 975 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S, 976 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S to the "TLS Cipher Suites" 977 registry with this document as reference, as shown below. 979 +----------+-----------------------------+-------+-----------+ 980 | Value | Description |DTLS-OK| Reference | 981 +----------+-----------------------------+-------+-----------+ 982 |0xC1, 0x03| TLS_GOSTR341112_256_ | N | this RFC | 983 | | _WITH_KUZNYECHIK_MGM_L | | | 984 +----------+-----------------------------+-------+-----------+ 985 |0xC1, 0x04| TLS_GOSTR341112_256_ | N | this RFC | 986 | | _WITH_MAGMA_MGM_L | | | 987 +----------+-----------------------------+-------+-----------+ 988 |0xC1, 0x05| TLS_GOSTR341112_256_ | N | this RFC | 989 | | _WITH_KUZNYECHIK_MGM_S | | | 990 +----------+-----------------------------+-------+-----------+ 991 |0xC1, 0x06| TLS_GOSTR341112_256_ | N | this RFC | 992 | | _WITH_MAGMA_MGM_S | | | 993 +----------+-----------------------------+-------+-----------+ 994 Table 6 996 IANA has added numbers 0x0709, 0x070A, 0x070B, 0x070C, 0x070D, 0x070E 997 and 0x070F with the names gostr34102012_256a, gostr34102012_256b, 998 gostr34102012_256c, gostr34102012_256d, gostr34102012_512a, 999 gostr34102012_512b, gostr34102012_512c to the "TLS SignatureScheme" 1000 registry, as shown below. 1002 +-----------+----------------------+---------+----------+ 1003 | Value | Description | DTLS-OK | Reference| 1004 +-----------+----------------------+---------+----------+ 1005 | 0x0709 | gostr34102012_256a | N | this RFC | 1006 +-----------+----------------------+---------+----------+ 1007 | 0x070A | gostr34102012_256b | N | this RFC | 1008 +-----------+----------------------+---------+----------+ 1009 | 0x070B | gostr34102012_256c | N | this RFC | 1010 +-----------+----------------------+---------+----------+ 1011 | 0x070C | gostr34102012_256d | N | this RFC | 1012 +-----------+----------------------+---------+----------+ 1013 | 0x070D | gostr34102012_512a | N | this RFC | 1014 +-----------+----------------------+---------+----------+ 1015 | 0x070E | gostr34102012_512b | N | this RFC | 1016 +-----------+----------------------+---------+----------+ 1017 | 0x070F | gostr34102012_512c | N | this RFC | 1018 +-----------+----------------------+---------+----------+ 1019 Table 7 1021 8. Historical considerations 1023 Due to historical reasons in addition to the curve identifier values 1024 listed in Table 5 there exist some additional identifier values that 1025 correspond to the signature schemes as follows. 1027 +--------------------+-------------------------------------------+ 1028 | Description | Curve Identifier Value | 1029 +--------------------+-------------------------------------------+ 1030 | gostr34102012_256b | id-GostR3410_2001-CryptoPro-XchA-ParamSet | 1031 | | id-tc26-gost-3410-2012-256-paramSetB | 1032 +--------------------+-------------------------------------------+ 1033 | gostr34102012_256c | id-tc26-gost-3410-2012-256-paramSetC | 1034 +--------------------+-------------------------------------------+ 1035 | gostr34102012_256d | id-GostR3410-2001-CryptoPro-XchB-ParamSet | 1036 | | id-tc26-gost-3410-2012-256-paramSetD | 1037 +--------------------+-------------------------------------------+ 1038 Table 8 1040 Client should be prepared to handle any of them correctly if 1041 corresponding signature scheme is included in the 1042 "signature_algorithms" or "signature_algorithms_cert" extensions. 1044 9. Security Considerations 1046 In order to create an effective implementation client and server 1047 SHOULD follow the rules below. 1049 1. While using TLSTREE algorithm function KDF_j, j = 1, 2, 3, SHOULD 1050 be invoked only if the record sequence number seqnum reaches such a 1051 value that 1053 seqnum & C_j != (seqnum - 1) & C_j. 1055 Otherwise the previous value should be used. 1057 2. For each pre-shared key value PSK the binder_key value should be 1058 computed only once within all connections where ClientHello message 1059 contains a "pre_shared_key" extension indicating this PSK value. 1061 In order to ensure the secure TLS 1.3 connection client and server 1062 SHOULD fulfil the following requirements. 1064 1. An internal PSK value is NOT RECOMMENDED to be used to establish 1065 more than one TLS 1.3 connection. 1067 2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection. The 1068 reasons for this restriction are that the 0-RTT data is not forward 1069 secret and is not resistant to replay attacks (see more in 1070 Section 2.3 of [RFC8446]). 1072 3. If client authentication is required, server SHOULD NOT send 1073 Application Data, NewSessionTicket and KeyUpdate messages prior to 1074 receiving the client's Authentication messages since any data sent at 1075 that point is being sent to an unauthenticated peer. 1077 4. External PSKs SHOULD be used only in PSK-with-ECDHE mode. In 1078 case of using external PSK in PSK-only mode the attack described in 1079 [Selfie] is possible which leads to the situation when client 1080 establishes connection to itself. One of the mitigations proposed in 1081 [Selfie] is to use certificates, however, in that case, an 1082 impersonation attack as in [AASS19] occurs. If the connections are 1083 established with additional usage of key_share extension (in PSK- 1084 with-ECDHE mode), then the adversary which just echoes messages 1085 cannot reveal the traffic key material (as long as the used group is 1086 secure). 1088 5. In case of using external PSK, the mutual authentication MUST be 1089 provided by the external PSK distribution mechanism between the 1090 endpoints which guarantees that the derived external PSK is unknown 1091 to anyone but the endpoints. In addition, the endpoint roles (i.e. 1092 client and server) MUST be fixed during this mechanism and each role 1093 can match only to one endpoint during the whole external PSK 1094 lifetime. 1096 10. References 1098 10.1. Normative References 1100 [DraftGostTLS12] 1101 Smyshlyaev, S., Belyavsky, D., and M. Saarinen, "GOST 1102 Cipher Suites for Transport Layer Security (TLS) Protocol 1103 Version 1.2", 2019, . 1106 [DraftMGM] 1107 Smyshlyaev, S., Nozdrunov, V., Shishkin, V., and E. 1108 Smyshlyaeva, "Multilinear Galois Mode (MGM)", 2019, 1109 . 1111 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1112 Requirement Levels", BCP 14, RFC 2119, 1113 DOI 10.17487/RFC2119, March 1997, 1114 . 1116 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 1117 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 1118 2013, . 1120 [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: 1121 Digital Signature Algorithm", RFC 7091, 1122 DOI 10.17487/RFC7091, December 2013, 1123 . 1125 [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher 1126 "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, 1127 . 1129 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 1130 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 1131 on the Cryptographic Algorithms to Accompany the Usage of 1132 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 1133 RFC 7836, DOI 10.17487/RFC7836, March 2016, 1134 . 1136 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1137 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1138 May 2017, . 1140 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1141 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1142 . 1144 [RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric 1145 Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, 1146 . 1148 10.2. Informative References 1150 [AASS19] Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A. 1151 Sokolov, "Continuing to reflect on TLS 1.3 with external 1152 PSK", Cryptology ePrint Archive Report 2019/421, April 1153 2019, . 1155 [GOST3410-2012] 1156 Federal Agency on Technical Regulating and Metrology, 1157 "Information technology. Cryptographic data security. 1158 Signature and verification processes of [electronic] 1159 digital signature", GOST R 34.10-2012, 2012. 1161 [GOST3411-2012] 1162 Federal Agency on Technical Regulating and Metrology, 1163 "Information technology. Cryptographic Data Security. 1164 Hashing function", GOST R 34.11-2012, 2012. 1166 [GOST3412-2015] 1167 Federal Agency on Technical Regulating and Metrology, 1168 "Information technology. Cryptographic data security. 1169 Block ciphers", GOST R 34.12-2015, 2015. 1171 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 1172 with PSK", Cryptology ePrint Archive Report 2019/347, 1173 April 2019, . 1175 Appendix A. Test Examples 1177 TODO 1179 Appendix B. Contributors 1181 o Lilia Akhmetzyanova 1182 CryptoPro 1183 lah@cryptopro.ru 1185 o Alexandr Sokolov 1186 CryptoPro 1187 sokolov@cryptopro.ru 1189 o Vasily Nikolaev 1190 CryptoPro 1191 nikolaev@cryptopro.ru 1193 o Lidia Nikiforova 1194 CryptoPro 1195 nikiforova@cryptopro.ru 1197 Appendix C. Acknowledgments 1199 Authors' Addresses 1201 Stanislav Smyshlyaev (editor) 1202 CryptoPro 1203 18, Suschevsky val 1204 Moscow 127018 1205 Russian Federation 1207 Phone: +7 (495) 995-48-20 1208 Email: svs@cryptopro.ru 1209 Evgeny Alekseev 1210 CryptoPro 1211 18, Suschevsky val 1212 Moscow 127018 1213 Russian Federation 1215 Email: alekseev@cryptopro.ru 1217 Ekaterina Griboedova 1218 CryptoPro 1219 18, Suschevsky val 1220 Moscow 127018 1221 Russian Federation 1223 Email: griboedova.e.s@gmail.com 1225 Alexandra Babueva 1226 CryptoPro 1227 18, Suschevsky val 1228 Moscow 127018 1229 Russian Federation 1231 Email: babueva@cryptopro.ru