idnits 2.17.1 draft-smyshlyaev-tls13-gost-suites-02.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 16, 2020) is 1408 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: December 18, 2020 A. Babueva 6 CryptoPro 7 June 16, 2020 9 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 10 1.3 11 draft-smyshlyaev-tls13-gost-suites-02 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 December 18, 2020. 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_t) in B_t and 183 1<=i<=j<=t; 185 |A| the byte length of the byte 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 E_i the elliptic curve indicated by client in 211 "supported_groups" extension; 213 m_i the order of group of points belonging to the 214 elliptic curve E_i; 216 q_i the cyclic subgroup order of group of points 217 belonging to the elliptic curve E_i; 219 h_i the cyclic subgroup cofactor which is equal to m_i / 220 q_i; 222 Q_sign the public key stored in endpoint's certificate; 224 d_sign the private key that corresponds to the Q_sign key; 226 P_i the point of the elliptic curve E_i of the order q_i; 228 (d_C^i, Q_C^i) the client's ephemeral key pair which consists of the 229 private key and the public key corresponding to the 230 elliptic curve E_i; 232 (d_S^i, Q_S^i) the server's ephemeral key pair which consists of the 233 private key and the public key corresponding to the 234 elliptic curve E_i; 236 O_i the zero point of the elliptic curve E_i. 238 4. Cipher Suite Definition 240 The cipher suite value is used to indicate a record protection 241 algorithm and a hash algorithm which an endpoint supports (see 242 Section 4.1.2 of [RFC8446]). 244 This section defines the following four TLS13_GOST cipher suites that 245 can be used to support Russian cryptographic algorithms: 247 CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}; 248 CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04}; 249 CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05}; 250 CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}; 252 Each cipher suite specifies a pair of the record protection algorithm 253 (see Section 4.1) and the hash algorithm (Section 4.2). 255 4.1. Record Protection Algorithm 257 In accordance with Section 5.2 of [RFC8446] the record protection 258 algorithm translates a TLSPlaintext structure into a TLSCiphertext 259 structure. If TLS13_GOST cipher suite is negotiated, the 260 encrypted_record field of the TLSCiphertext structure MUST be set to 261 the AEADEncrypted value computed as follows: 263 AEADEncrypted = AEAD-Encrypt(sender_record_write_key, nonce, 264 additional_data, plaintext), 266 where 268 o the AEAD-Encrypt function is defined in Section 4.1.1; 270 o the sender_record_write_key is derived from the sender_write_key 271 (see Section 7.3 of [RFC8446]) using TLSTREE function defined in 272 Section 4.1.2 and sequence number seqnum as follows: 274 sender_record_write_key = TLSTREE(sender_write_key, seqnum); 276 o the nonce value is derived from the record sequence number seqnum 277 and the sender_write_iv value (see Section 7.3 of [RFC8446]) in 278 accordance with Section 5.3 of [RFC8446]; 280 o the additional_data value is the record header that is generated 281 in accordance with Section 5.2 of [RFC8446]; 283 o the plaintext value is the TLSInnerPlaintext structure encoded in 284 accordance with Section 5.2 of [RFC8446]; 286 Note1: The AEAD-Encrypt function is exactly the same as the AEAD- 287 Encrypt function defined in [RFC8446] except the key (the first 288 argument) is calculated from the sender_write key and sequence number 289 seqnum for each message separately to support external re-keying 290 approach according to [RFC8645]. 292 Note2: The record sequence number is the value in the range 0-SNMAX, 293 where the SNMAX value is defined in Section 4.1.3. The SNMAX 294 parameter is specified by the particular TLS13_GOST cipher suite to 295 limit the amount of data that can be encrypted under the same traffic 296 key material (sender_write_key, sender_write_iv). 298 The record deprotection algorithm reverses the process of the record 299 protection. In order to decrypt and verify the protected record with 300 sequence number seqnum the algorithm takes as input the 301 sender_record_write_key is derived from the sender_write_key, nonce, 302 additional data and the AEADEncrypted value and outputs the res value 303 which is either the plaintext or an error indicating that the 304 decryption failed. If TLS13_GOST cipher suite is negotiated, the res 305 value MUST be computed as follows: 307 res = AEAD-Decrypt(sender_record_write_key, nonce, 308 additional_data, AEADEncrypted), 310 where the AEAD-Decrypt function is defined in Section 4.1.1. 312 Note: The AEAD-Decrypt function is exactly the same as the AEAD- 313 Decrypt function defined in [RFC8446] except the key (the first 314 argument) is calculated from the sender_write key and sequence number 315 seqnum for each message separately to support external re-keying 316 approach according to [RFC8645]. 318 4.1.1. AEAD Algorithm 320 The AEAD-Encrypt and AEAD-Decrypt functions are defined as follows. 322 +-------------------------------------------------------------------+ 323 | AEAD-Encrypt(K, nonce, A, P) | 324 |-------------------------------------------------------------------| 325 | Input: | 326 | - encryption key K in B_k, | 327 | - unique vector nonce in B_IVlen, | 328 | - additional authenticated data A in B_r, r >= 0, | 329 | - plaintext P in B_t, t >= 0. | 330 | Output: | 331 | - ciphertext C in B_{|P|}, | 332 | - authentication tag T in B_S. | 333 |-------------------------------------------------------------------| 334 | 1. MGMnonce = nonce[1..1] & 0x7f | nonce[2..IVlen]; | 335 | 2. (MGMnonce, A, C, T) = MGM-Encrypt(K, MGMnonce, A, P); | 336 | 3. Return C | T. | 337 +-------------------------------------------------------------------+ 339 +-------------------------------------------------------------------+ 340 | AEAD-Decrypt(K, nonce, A, C | T) | 341 |-------------------------------------------------------------------| 342 | Input: | 343 | - encryption key K in B_k, | 344 | - unique vector nonce in B_IVlen, | 345 | - additional authenticated data A in B_r, r >= 0, | 346 | - ciphertext C in B_t, t >= 0, | 347 | - authentication tag T in B_S. | 348 | Output: | 349 | - plaintext P in B_{|C|} or FAIL. | 350 |-------------------------------------------------------------------| 351 | 1. MGMnonce = nonce[1..1] & 0x7f | nonce[2..IVlen]; | 352 | 2. res' = MGM-Decrypt(K, MGMnonce, A, C, T); | 353 | 3. IF res' = FAIL then return FAIL; else return P. | 354 +-------------------------------------------------------------------+ 356 where 358 o MGM-Encrypt and MGM-Decrypt functions are defined in [DraftMGM]. 359 The size of the authentication tag T is equal to n bytes (S = n). 360 The size of the nonce parameter is equal to n bytes (IVlen = n). 362 The cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and 363 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik 364 [RFC7801] as a base block cipher for the AEAD algorithm. The block 365 length n is 16 bytes (n = 16) and the key length k is 32 bytes (k = 366 32). 368 The cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and 369 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST use Magma [GOST3412-2015] 370 as a base block cipher for the AEAD algorithm. The block length n is 371 8 bytes (n = 8) and the key length k is 32 bytes (k = 32). 373 4.1.2. TLSTREE 375 The TLS13_GOST cipher suites use the TLSTREE function for the 376 external re-keying approach (see [RFC8645]). The TLSTREE function is 377 defined as follows: 379 TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8(i & C_1)), 380 STR_8(i & C_2)), STR_8(i & C_3)), 382 where 384 o K_root in B_32; 386 o i in {0, 1, ... , 2^64 - 1}; 388 o KDF_j(K, D), j = 1, 2, 3, is the key derivation function defined 389 as follows: 391 KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D), 392 KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D), 393 KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D), 395 where the KDF_GOSTR3411_2012_256 function is defined in [RFC7836], 396 K in B_32, D in B_8. 398 o C_1, C_2, C_3 are constants defined by the particular cipher suite 399 as follows: 401 +------------------------------------------+----------------------+ 402 | CipherSuites | C_1, C_2, C_3 | 403 +------------------------------------------+----------------------+ 404 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L |C_1=0xf800000000000000| 405 | |C_2=0xfffffff000000000| 406 | |C_3=0xffffffffffffe000| 407 +------------------------------------------+----------------------+ 408 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L |C_1=0xffe0000000000000| 409 | |C_2=0xffffffffc0000000| 410 | |C_3=0xffffffffffffff80| 411 +------------------------------------------+----------------------+ 412 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S |C_1=0xffffffffe0000000| 413 | |C_2=0xffffffffffff0000| 414 | |C_3=0xfffffffffffffff8| 415 +------------------------------------------+----------------------+ 416 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S |C_1=0xfffffffffc000000| 417 | |C_2=0xffffffffffffe000| 418 | |C_3=0xffffffffffffffff| 419 +------------------------------------------+----------------------+ 420 Table 1 422 4.1.3. SNMAX parameter 424 The SNMAX parameter is the maximum number of records encrypted under 425 the same traffic key material (sender_write_key and sender_write_iv) 426 and is defined by the particular cipher suite as follows: 428 +------------------------------------------+--------------------+ 429 | CipherSuites | SNMAX | 430 +------------------------------------------+--------------------+ 431 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L | SNMAX = 2^64 - 1 | 432 +------------------------------------------+--------------------+ 433 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L | SNMAX = 2^64 - 1 | 434 +------------------------------------------+--------------------+ 435 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S | SNMAX = 2^42 - 1 | 436 +------------------------------------------+--------------------+ 437 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | SNMAX = 2^39 - 1 | 438 +------------------------------------------+--------------------+ 439 Table 2 441 4.2. Hash Algorithm 443 The Hash algorithm is used for key derivation process (see 444 Section 7.1 of [RFC8446]), Finished message calculation (see 445 Section 4.4.4 of [RFC8446]), Transcript-Hash function computation 446 (see Section 4.4.1 of [RFC8446]), PSK binder value calculation (see 447 Section 4.2.11.2 of [RFC8446]), external re-keying approach (see 448 Section 4.1.2) and other purposes. 450 In case of negotiating a TLS13_GOST cipher suite the Hash algorithm 451 MUST be the GOST R 34.11-2012 [RFC6986] hash algorithm with 32-byte 452 (256-bit) hash value. 454 5. Signature Scheme Definition 456 The signature scheme value is used to indicate a single signature 457 algorithm and a curve that can be used in digital signature (see 458 Section 4.2.3 of [RFC8446]). 460 This section defines the following seven TLS13_GOST signature schemes 461 that can be used to support Russian cryptographic algorithms: 463 enum { 464 gostr34102012_256a(0x0709), 465 gostr34102012_256b(0x070A), 466 gostr34102012_256c(0x070B), 467 gostr34102012_256d(0x070C), 468 gostr34102012_512a(0x070D), 469 gostr34102012_512b(0x070E), 470 gostr34102012_512c(0x070F) 471 } SignatureScheme; 473 If TLS13_GOST cipher suite is negotiated and authentication via 474 certificates is required one of the TLS13_GOST signature schemes 475 listed above SHOULD be used. 477 Each signature scheme specifies a pair of the signature algorithm 478 (see Section 5.1) and the elliptic curve (see Section 5.2). 480 5.1. Signature Algorithm 482 Signature algorithms corresponding to the TLS13_GOST signature 483 schemes are defined as follows: 485 +------------------+--------------------------------------+--------+ 486 | SignatureScheme | Signature Algorithm | Refe- | 487 | Value | | rences | 488 +------------------+--------------------------------------+--------+ 489 |gostr34102012_256a|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 490 +------------------+--------------------------------------+--------+ 491 |gostr34102012_256b|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 492 +------------------+--------------------------------------+--------+ 493 |gostr34102012_256c|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 494 +------------------+--------------------------------------+--------+ 495 |gostr34102012_256d|GOST R 34.10-2012 , 32-byte key length|RFC 7091| 496 +------------------+--------------------------------------+--------+ 497 |gostr34102012_512a|GOST R 34.10-2012 , 64-byte key length|RFC 7091| 498 +------------------+--------------------------------------+--------+ 499 |gostr34102012_512b|GOST R 34.10-2012 , 64-byte key length|RFC 7091| 500 +------------------+--------------------------------------+--------+ 501 |gostr34102012_512c|GOST R 34.10-2012 , 64-byte key length|RFC 7091| 502 +------------------+--------------------------------------+--------+ 503 Table 3 505 5.2. Elliptic Curve 507 Elliptic curves corresponding to the TLS13_GOST signature schemes are 508 defined as follows: 510 +------------------+--------------------------------------+--------+ 511 | SignatureScheme | Curve Identifier Value | Refe- | 512 | Value | | rences | 513 +------------------+--------------------------------------+--------+ 514 |gostr34102012_256a| id-tc26-gost-3410-2012-256-paramSetA |RFC 7836| 515 +------------------+--------------------------------------+--------+ 516 |gostr34102012_256b|id-GostR3410-2001-CryptoPro-A-ParamSet|RFC 4357| 517 +------------------+--------------------------------------+--------+ 518 |gostr34102012_256c|id-GostR3410-2001-CryptoPro-B-ParamSet|RFC 4357| 519 +------------------+--------------------------------------+--------+ 520 |gostr34102012_256d|id-GostR3410-2001-CryptoPro-C-ParamSet|RFC 4357| 521 +------------------+--------------------------------------+--------+ 522 |gostr34102012_512a| id-tc26-gost-3410-12-512-paramSetA |RFC 7836| 523 +------------------+--------------------------------------+--------+ 524 |gostr34102012_512b| id-tc26-gost-3410-12-512-paramSetB |RFC 7836| 525 +------------------+--------------------------------------+--------+ 526 |gostr34102012_512c| id-tc26-gost-3410-2012-512-paramSetC |RFC 7836| 527 +------------------+--------------------------------------+--------+ 528 Table 4 530 5.3. SIGN function 532 If TLS13_GOST signature scheme is used, the signature value in 533 CertificateVerify message (see Section 6.3.4) MUST be calculated 534 using the SIGN function defined as follows: 536 +-----------------------------------------------------+ 537 | SIGN(M, d_sign) | 538 |-----------------------------------------------------| 539 | Input: | 540 | - the byte string M in B*; | 541 | - the sign key d_sign: 0 < d_sign < q. | 542 | Output: | 543 | - signature value sgn in B_{2*l}. | 544 |-----------------------------------------------------| 545 | 1. (r, s) = SIGNGOST(M, d_sign) | 546 | 2. Return str_l(r) | str_l(s) | 547 |-----------------------------------------------------+ 549 where 551 o q is the subgroup order of group of points of the elliptic curve; 553 o l is defined as follows: 555 * l = 32 for gostr34102012_256a, gostr34102012_256b, 556 gostr34102012_256c and gostr34102012_256d signature schemes; 558 * l = 64 for gostr34102012_512a, gostr34102012_512b and 559 gostr34102012_512c signature schemes; 561 o SIGNGOST is an algorithm which takes as an input message M and 562 private key d_sign and returns a pair of integers (r, s) 563 calculated during signature generation process in accordance with 564 the GOST R 34.10-2012 signature algorithm (see Section 6.1 of 565 [RFC7091]). 567 Note: The signature value sgn is the concatenation of two strings 568 that are byte representations of r and s values in the little-endian 569 format. 571 6. Key Exchange and Authentication 573 Key exchange and authentication process in case of using TLS13_GOST 574 cipher suites is defined in Section 6.1, Section 6.2 and Section 6.3. 576 6.1. Key Exchange 578 TLS13_GOST cipher suites support three basic key exchange modes which 579 are defined in [RFC8446]: ECDHE, PSK-only and PSK-with-ECDHE. 581 Note: In accordance with [RFC8446] TLS 1.3 also supports key exchange 582 modes based on Diffie-Hellman protocol over finite fields. However, 583 TLS13_GOST cipher suites SHOULD use only modes based on Diffie- 584 Hellman protocol over elliptic curves. 586 In accordance with [RFC8446] PSKs can be divided into two types: 588 o internal PSKs which can be established during the previous 589 connection; 591 o external PSKs which can be established out of band. 593 If TLS13_GOST cipher suite is negotiated, PSK-only key exchange mode 594 SHOULD be established only via the internal PSKs, and external PSKs 595 SHOULD be used only in PSK-with-ECDHE mode (see more in Section 9). 597 If TLS13_GOST cipher suite is negotiated and ECDHE or PSK-with-ECDHE 598 key exchange mode is used the ECDHE shared secret value SHOULD be 599 calculated in accordance with Section 6.1.1 on the basis of one of 600 the elliptic curves defined in Section 6.1.2. 602 6.1.1. ECDHE Shared Secret Calculation 604 If TLS13_GOST cipher suite is negotiated, ECDHE shared secret value 605 SHOULD be calculated in accordance with Section 6.1.1.1 and 606 Section 6.1.1.2. The public ephemeral keys used to obtain ECDHE 607 shared secret value SHOULD be represented in format described in 608 Section 6.1.1.3. 610 6.1.1.1. ECDHE Shared Secret Calculation on Client Side 612 The client calculates ECDHE shared secret value in accordance with 613 the following steps: 615 1. Chooses from all supported curves E_1, ..., E_R the set of curves 616 E_{i_1}, ..., E_{i_r}, 1 <= i_1 <= i_r <= R, where 618 o r >= 1 in the case of the first ClientHello message; 620 o r = 1 in the case of responding to HelloRetryRequest message, 621 E_{i_1} corresponds to the curve indicated in the "key_share" 622 extension in the HelloRetryRequest message. 624 2. Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ..., 625 (d_C^{i_r}, Q_C^{i_r}) corresponding to the curves E_{i_1}, ..., 626 E_{i_r}, where for each i in {i_1, ..., i_r}: 628 o d_C^i is chosen from {1, ..., q_i - 1} at random; 630 o Q_C^i = d_C^i * P_i. 632 3. Sends ClientHello message specified in accordance with 633 Section 4.1.2 of [RFC8446] and Section 6.3.1, which contains: 635 o "key_share" extension with public ephemeral keys Q_C^{i_1}, ..., 636 Q_C^{i_r} generated in accordance with Section 4.2.8 of [RFC8446]; 638 o "supported_groups" extension with supported curves E_1, ..., E_R 639 generated in accordance with Section 4.2.7 of [RFC8446]. 641 Note: Client MAY send an empty "key_share" extension in the first 642 ClientHello in order to request group selection from the server in 643 the HelloRetryRequest message and to generate ephemeral key for the 644 selected group only. The ECDHE value may be calculated without 645 sending HelloRetryRequest, if the "key_share" extension in the first 646 ClientHello message consists the value corresponded to the curve that 647 will be selected by the server. 649 4. In case of receiving HelloRetryRequest message client SHOULD 650 return to step 1 and correct parameters in accordance with 651 Section 4.1.2 of [RFC8446]. In case of receiving ServerHello message 652 client proceeds to the next step. In other cases client MUST 653 terminate the connection with "unexpected_message" alert. 655 5. Extracts curve E_res and ephemeral key Q_S^res, res in {1, ..., 656 R}, from ServerHello message and checks whether the Q_S^res belongs 657 to E_res. If this check fails, the client MUST abort the handshake 658 with "handshake_failure" alert. 660 6. Generates Q^ECDHE: 662 Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) * Q_S^res. 664 7. Client MUST check whether the computed shared secret Q^ECDHE is 665 not equal to the zero point O_res. If this check fails, the client 666 MUST abort the handshake with "handshake_failure" alert. 668 8. Shared secret value ECDHE is the byte representation of the 669 coordinate X^ECDHE of point Q^ECDHE in the little-endian format: 671 ECDHE = str_{coordinate_length}(X^ECDHE), 673 where the coordinate_length value is defined by the particular 674 elliptic curve (see Section 6.1.2). 676 6.1.1.2. ECDHE Shared Secret Calculation on Server Side 678 Upon receiving the ClientHello message, the server calculates ECDHE 679 shared secret value in accordance with the following steps: 681 1. Chooses the curve E_res, res in {1, ..., R}, from the list of the 682 curves E_1, ..., E_R indicated in "supported_groups" extension in 683 ClientHello message and the corresponding public ephemeral key value 684 Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r}, 1 <= i_1 <= i_r <= 685 R, indicated in "key_share" extension. If no corresponding public 686 ephemeral key value is found (res in {1, ..., R}\{i_1, ..., i_r}), 687 server MAY send HelloRetryRequest message with "key_share" extension 688 indicating the selected elliptic curve E_res and wait for the new 689 ClientHello message. 691 2. Checks whether Q_C^res belongs to E_res. If this check fails, 692 the server MUST abort the handshake with "handshake_failure" alert. 694 3. Generates ephemeral key pair (d_S^res, Q_S^res) corresponding to 695 E_res: 697 o d_S^res is chosen from {1, ..., q_res - 1} at random; 699 o Q_S^res = d_S^res * P_res. 701 4. Sends ServerHello message generated in accordance with 702 Section 4.1.3 of [RFC8446] and Section 6.3.1 with "key_share" 703 extension which contains public ephemeral key value Q_S^res 704 corresponding to E_res. 706 5. Generates Q^ECDHE: 708 Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res. 710 6. Server MUST check whether the computed shared secret Q^ECDHE is 711 not equal to the zero point O_res. If this check fails, the server 712 MUST abort the handshake with "handshake_failure" alert. 714 7. Shared secret value ECDHE is the byte representation of the 715 coordinate X^ECDHE of point Q^ECDHE in the little-endian format: 717 ECDHE = str_{coordinate_length}(X^ECDHE), 719 where the coordinate_length value is defined by the particular 720 elliptic curve (see Section 6.1.2). 722 6.1.1.3. Public ephemeral key representation 724 This section defines the representation format of the public 725 ephemeral keys generated during ECDHE shared secret calculation (see 726 Section 6.1.1.1 and Section 6.1.1.2). 728 If TLS13_GOST cipher suite is negotiated and ECDHE or PSK-with-ECDHE 729 key exchange mode is used, the public ephemeral key Q indicated in 730 the KeyShareEntry.key_exchange field SHOULD contain the data defined 731 by the following structure: 733 struct { 734 opaque X[coordinate_length]; 735 opaque Y[coordinate_length]; 736 } PlainPointRepresentation; 738 where X and Y, respectively, contain the byte representations of the 739 x and the y values of point Q (Q = (x, y)) in the little-endian 740 format and are specified as follows: 742 X = str_{coordinate_length}(x); 744 Y = str_{coordinate_length}(y). 746 The coordinate_length value is defined by the particular elliptic 747 curve (see Section 6.1.2). 749 6.1.2. Values for the TLS Supported Groups Registry 751 The "supported_groups" extension is used to indicate the set of the 752 elliptic curves supported by an endpoint and is defined in 753 Section 4.2.7 [RFC8446]. This extension is always contained in 754 ClientHello message and optionally in EncryptedExtensions message. 756 This section defines the following seven elliptic curves that can be 757 used to support Russian cryptographic algorithms: 759 enum { 760 GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25), 761 GC512A(0x26), GC512B(0x27), GC512C(0x28) 762 } NamedGroup; 763 If TLS13_GOST cipher suite is negotiated and ECDHE or PSK-with-ECDHE 764 key exchange mode is established, one of the elliptic curves listed 765 above SHOULD be used. 767 Each curve corresponds to the particular identifier and specifies the 768 value of coordinate_length parameter (see "cl" column) as follows: 770 +-----------+--------------------------------------+----+---------+ 771 |Description| Curve Identifier Value | cl |Reference| 772 +-----------+--------------------------------------+----+---------+ 773 | GC256A | id-tc26-gost-3410-2012-256-paramSetA | 32 | RFC 7836| 774 +-----------+--------------------------------------+----+---------+ 775 | GC256B |id-GostR3410-2001-CryptoPro-A-ParamSet| 32 | RFC 4357| 776 +-----------+--------------------------------------+----+---------+ 777 | GC256C |id-GostR3410-2001-CryptoPro-B-ParamSet| 32 | RFC 4357| 778 +-----------+--------------------------------------+----+---------+ 779 | GC256D |id-GostR3410-2001-CryptoPro-C-ParamSet| 32 | RFC 4357| 780 +-----------+--------------------------------------+----+---------+ 781 | GC512A | id-tc26-gost-3410-12-512-paramSetA | 64 | RFC 7836| 782 +-----------+--------------------------------------+----+---------+ 783 | GC512B | id-tc26-gost-3410-12-512-paramSetB | 64 | RFC 7836| 784 +-----------+--------------------------------------+----+---------+ 785 | GC512C | id-tc26-gost-3410-2012-512-paramSetC | 64 | RFC 7836| 786 +-----------+--------------------------------------+----+---------+ 787 Table 5 789 Note: The identifier values and the corresponding elliptic curves are 790 the same as in [DraftGostTLS12]. 792 6.2. Authentication 794 In accordance with [RFC8446] authentication can happen via signature 795 with certificate or via symmetric pre-shared key (PSK). The server 796 side of the channel is always authenticated; the client side is 797 optionally authenticated. 799 PSK-based authentication happens as a side effect of key exchange. 800 If TLS13_GOST cipher suite is negotiated, external PSKs SHOULD be 801 combined only with the mutual authentication (see more in Section 9). 803 Certificate-based authentication happens via Authentication messages 804 and optional CertificateRequest message (sent if client 805 authentication is required). In case of negotiating TLS13_GOST 806 cipher suites the signature schemes used for certificate-based 807 authentication are defined in Section 5 and the Authentication 808 messages are specified in Section 6.3.3 and Section 6.3.4. The 809 CertificateRequest message is specified in Section 6.3.2. 811 6.3. Handshake Messages 813 The TLS13_GOST cipher suites specify the ClientHello, ServerHello, 814 CertificateRequest, Certificate and CertificateVerify handshake 815 messages that are described in further detail below. 817 6.3.1. Hello Messages 819 The ClientHello message is sent when a client first connects to a 820 server or responds to a HelloRetryRequest message and is specified in 821 accordance with [RFC8446] as follows. 823 struct { 824 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 825 Random random; 826 opaque legacy_session_id<0..32>; 827 CipherSuite cipher_suites<2..2^16-2>; 828 opaque legacy_compression_methods<1..2^8-1>; 829 Extension extensions<8..2^16-1>; 830 } ClientHello; 832 In order to negotiate a TLS13_GOST cipher suite, the ClientHello 833 message MUST meet the following requirements. 835 o The ClientHello.cipher_suites field MUST contain the values 836 defined in Section 4. 838 o If server authentication via a certificate is required, the 839 extension_data field of the "signature_algorithms" extension MUST 840 contain the values defined in Section 5, which correspond to the 841 GOST R 34.10-2012 signature algorithm. 843 o If server authentication via a certificate is required and the 844 client uses optional "signature_algorithms_cert" extension, the 845 extension_data field of this extension MUST contain the values 846 defined in Section 5, which correspond to the GOST R 34.10-2012 847 signature algorithm. 849 o If client wants to establish TLS 1.3 connection using ECDHE shared 850 secret value, the extension_data field of the "supported_groups" 851 extension MUST contain the elliptic curve identifiers defined in 852 Section 6.1.2. 854 The ServerHello message is sent by the server in response to a 855 ClientHello message to negotiate an acceptable set of handshake 856 parameters based on the ClientHello and is specified in accordance 857 with [RFC8446] as follows. 859 struct { 860 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 861 Random random; 862 opaque legacy_session_id_echo<0..32>; 863 CipherSuite cipher_suite; 864 uint8 legacy_compression_method = 0; 865 Extension extensions<6..2^16-1>; 866 } ServerHello; 868 In case of negotiating a TLS13_GOST cipher suite, the ServerHello 869 message MUST meet the following requirements. 871 o The ServerHello.cipher_suite field MUST contain one of the values 872 defined in Section 4. 874 o If server decides to establish TLS 1.3 connection using ECDHE 875 shared secret value, the extension_data field of the "key_share" 876 extension MUST contain the elliptic curve identifier and the 877 public ephemeral key that satisfy the following conditions. 879 * The elliptic curve identifier corresponds to a value that was 880 provided in the "supported_groups" and the "key_share" 881 extensions in the ClientHello message. 883 * The elliptic curve identifier is one of the values defined in 884 Section 6.1.2. 886 * The public ephemeral key corresponds to the elliptic curve 887 specified by the KeyShareEntry.group identifier. 889 6.3.2. CertificateRequest 891 This message is sent when server requests client authentication via a 892 certificate and is specified in accordance with [RFC8446] as follows. 894 struct { 895 opaque certificate_request_context<0..2^8-1>; 896 Extension extensions<2..2^16-1>; 897 } CertificateRequest; 898 If TLS13_GOST cipher suite is negotiated, the CertificateRequest 899 message MUST meet the following requirements. 901 o The extension_data field of the "signature_algorithms" extension 902 MUST contain only the values defined in Section 5. 904 o If server uses optional "signature_algorithms_cert" extension, the 905 extension_data field of this extension MUST contain only the 906 values defined in Section 5. 908 6.3.3. Certificate 910 This message is sent to convey the endpoint's certificate chain to 911 the peer and is specified in accordance with [RFC8446] as follows. 913 struct { 914 opaque certificate_request_context<0..2^8-1>; 915 CertificateEntry certificate_list<0..2^24-1>; 916 } Certificate; 918 If TLS13_GOST cipher suite is negotiated, the Certificate message 919 MUST meet the following requirements. 921 o Each endpoint's certificate provided to the peer MUST be signed 922 using the algorithm which corresponds to a signature scheme 923 indicated by the peer in its "signature_algoritms_cert" extension, 924 if present (or in the "signature_algorithms" extension, 925 otherwise). 927 o The signature algorithm used for signing certificates MUST 928 correspond to the one of the signature schemes defined in 929 Section 5. 931 6.3.4. CertificateVerify 933 This message is sent to provide explicit proof that an endpoint 934 possesses the private key corresponding to the public key indicated 935 in its certificate and is specified in accordance with [RFC8446] as 936 follows. 938 struct { 939 SignatureScheme algorithm; 940 opaque signature<0..2^16-1>; 941 } CertificateVerify; 942 If TLS13_GOST cipher suite is negotiated, the CertificateVerify 943 message MUST meet the following requirements. 945 o The CertificateVerify.algorithm field MUST contain the signature 946 scheme identifier which corresponds to the value indicated in the 947 peer's "signature_algorithms" extension and which is one of the 948 values defined in Section 5. 950 o The CertificateVerify.signature field contains the sgn value, 951 which is computed as follows: 953 sgn = SIGN(M, d_sign), 955 o where 957 * the SIGN function is defined in Section 5, 959 * the message M is defined in accordance with Section 4.4.3 of 960 [RFC8446], 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 7. IANA Considerations 968 IANA has added numbers {0xC1, 0x03}, {0xC1, 0x04}, {0xC1, 0x05} and 969 {0xC1, 0x06} with the names 970 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L, 971 TLS_GOSTR341112_256_WITH_MAGMA_MGM_L, 972 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S, 973 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S to the "TLS Cipher Suites" 974 registry with this document as reference, as shown below. 976 +----------+-----------------------------+-------+-----------+ 977 | Value | Description |DTLS-OK| Reference | 978 +----------+-----------------------------+-------+-----------+ 979 |0xC1, 0x03| TLS_GOSTR341112_256_ | N | this RFC | 980 | | _WITH_KUZNYECHIK_MGM_L | | | 981 +----------+-----------------------------+-------+-----------+ 982 |0xC1, 0x04| TLS_GOSTR341112_256_ | N | this RFC | 983 | | _WITH_MAGMA_MGM_L | | | 984 +----------+-----------------------------+-------+-----------+ 985 |0xC1, 0x05| TLS_GOSTR341112_256_ | N | this RFC | 986 | | _WITH_KUZNYECHIK_MGM_S | | | 987 +----------+-----------------------------+-------+-----------+ 988 |0xC1, 0x06| TLS_GOSTR341112_256_ | N | this RFC | 989 | | _WITH_MAGMA_MGM_S | | | 990 +----------+-----------------------------+-------+-----------+ 991 Table 6 993 IANA has added numbers 0x0709, 0x070A, 0x070B, 0x070C, 0x070D, 0x070E 994 and 0x070F with the names gostr34102012_256a, gostr34102012_256b, 995 gostr34102012_256c, gostr34102012_256d, gostr34102012_512a, 996 gostr34102012_512b, gostr34102012_512c to the "TLS SignatureScheme" 997 registry, as shown below. 999 +-----------+----------------------+---------+----------+ 1000 | Value | Description | DTLS-OK | Reference| 1001 +-----------+----------------------+---------+----------+ 1002 | 0x0709 | gostr34102012_256a | N | this RFC | 1003 +-----------+----------------------+---------+----------+ 1004 | 0x070A | gostr34102012_256b | N | this RFC | 1005 +-----------+----------------------+---------+----------+ 1006 | 0x070B | gostr34102012_256c | N | this RFC | 1007 +-----------+----------------------+---------+----------+ 1008 | 0x070C | gostr34102012_256d | N | this RFC | 1009 +-----------+----------------------+---------+----------+ 1010 | 0x070D | gostr34102012_512a | N | this RFC | 1011 +-----------+----------------------+---------+----------+ 1012 | 0x070E | gostr34102012_512b | N | this RFC | 1013 +-----------+----------------------+---------+----------+ 1014 | 0x070F | gostr34102012_512c | N | this RFC | 1015 +-----------+----------------------+---------+----------+ 1016 Table 7 1018 8. Historical considerations 1020 Due to historical reasons in addition to the curve identifier values 1021 listed in Table 5 there exist some additional identifier values that 1022 correspond to the signature schemes as follows. 1024 +--------------------+-------------------------------------------+ 1025 | Description | Curve Identifier Value | 1026 +--------------------+-------------------------------------------+ 1027 | gostr34102012_256b | id-GostR3410_2001-CryptoPro-XchA-ParamSet | 1028 | | id-tc26-gost-3410-2012-256-paramSetB | 1029 +--------------------+-------------------------------------------+ 1030 | gostr34102012_256c | id-tc26-gost-3410-2012-256-paramSetC | 1031 +--------------------+-------------------------------------------+ 1032 | gostr34102012_256d | id-GostR3410-2001-CryptoPro-XchB-ParamSet | 1033 | | id-tc26-gost-3410-2012-256-paramSetD | 1034 +--------------------+-------------------------------------------+ 1035 Table 8 1037 Client should be prepared to handle any of them correctly if 1038 corresponding signature scheme is included in the 1039 "signature_algorithms" or "signature_algorithms_cert" extensions. 1041 9. Security Considerations 1043 In order to create an effective implementation client and server 1044 SHOULD follow the rules below. 1046 1. While using TLSTREE algorithm function KDF_j, j = 1, 2, 3, SHOULD 1047 be invoked only if the record sequence number seqnum reaches such a 1048 value that 1050 seqnum & C_j != (seqnum - 1) & C_j. 1052 Otherwise the previous value should be used. 1054 2. For each pre-shared key value PSK the binder_key value should be 1055 computed only once within all connections where ClientHello message 1056 contains a "pre_shared_key" extension indicating this PSK value. 1058 In order to ensure the secure TLS 1.3 connection client and server 1059 SHOULD fulfil the following requirements. 1061 1. An internal PSK value is NOT RECOMMENDED to be used to establish 1062 more than one TLS 1.3 connection. 1064 2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection. The 1065 reasons for this restriction are that the 0-RTT data is not forward 1066 secret and is not resistant to replay attacks (see more in 1067 Section 2.3 of [RFC8446]). 1069 3. If client authentication is required, server SHOULD NOT send 1070 Application Data, NewSessionTicket and KeyUpdate messages prior to 1071 receiving the client's Authentication messages since any data sent at 1072 that point is being sent to an unauthenticated peer. 1074 4. External PSKs SHOULD be used only in PSK-with-ECDHE mode. In 1075 case of using external PSK in PSK-only mode the attack described in 1076 [Selfie] is possible which leads to the situation when client 1077 establishes connection to itself. One of the mitigations proposed in 1078 [Selfie] is to use certificates, however, in that case, an 1079 impersonation attack as in [AASS19] occurs. If the connections are 1080 established with additional usage of key_share extension (in PSK- 1081 with-ECDHE mode), then the adversary which just echoes messages 1082 cannot reveal the traffic key material (as long as the used group is 1083 secure). 1085 5. In case of using external PSK, the mutual authentication MUST be 1086 provided by the external PSK distribution mechanism between the 1087 endpoints which guarantees that the derived external PSK is unknown 1088 to anyone but the endpoints. In addition, the endpoint roles (i.e. 1089 client and server) MUST be fixed during this mechanism and each role 1090 can match only to one endpoint during the whole external PSK 1091 lifetime. 1093 10. References 1095 10.1. Normative References 1097 [DraftGostTLS12] 1098 Smyshlyaev, S., Belyavsky, D., and M. Saarinen, "GOST 1099 Cipher Suites for Transport Layer Security (TLS) Protocol 1100 Version 1.2", 2019, . 1103 [DraftMGM] 1104 Smyshlyaev, S., Nozdrunov, V., Shishkin, V., and E. 1105 Smyshlyaeva, "Multilinear Galois Mode (MGM)", 2019, 1106 . 1108 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1109 Requirement Levels", BCP 14, RFC 2119, 1110 DOI 10.17487/RFC2119, March 1997, 1111 . 1113 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 1114 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 1115 2013, . 1117 [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: 1118 Digital Signature Algorithm", RFC 7091, 1119 DOI 10.17487/RFC7091, December 2013, 1120 . 1122 [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher 1123 "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, 1124 . 1126 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 1127 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 1128 on the Cryptographic Algorithms to Accompany the Usage of 1129 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 1130 RFC 7836, DOI 10.17487/RFC7836, March 2016, 1131 . 1133 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1134 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1135 May 2017, . 1137 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1138 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1139 . 1141 [RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric 1142 Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, 1143 . 1145 10.2. Informative References 1147 [AASS19] Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A. 1148 Sokolov, "Continuing to reflect on TLS 1.3 with external 1149 PSK", Cryptology ePrint Archive Report 2019/421, April 1150 2019, . 1152 [GOST3410-2012] 1153 Federal Agency on Technical Regulating and Metrology, 1154 "Information technology. Cryptographic data security. 1155 Signature and verification processes of [electronic] 1156 digital signature", GOST R 34.10-2012, 2012. 1158 [GOST3411-2012] 1159 Federal Agency on Technical Regulating and Metrology, 1160 "Information technology. Cryptographic Data Security. 1161 Hashing function", GOST R 34.11-2012, 2012. 1163 [GOST3412-2015] 1164 Federal Agency on Technical Regulating and Metrology, 1165 "Information technology. Cryptographic data security. 1166 Block ciphers", GOST R 34.12-2015, 2015. 1168 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 1169 with PSK", Cryptology ePrint Archive Report 2019/347, 1170 April 2019, . 1172 Appendix A. Test Examples 1174 TODO 1176 Appendix B. Contributors 1178 o Lilia Akhmetzyanova 1179 CryptoPro 1180 lah@cryptopro.ru 1182 o Alexandr Sokolov 1183 CryptoPro 1184 sokolov@cryptopro.ru 1186 o Vasily Nikolaev 1187 CryptoPro 1188 nikolaev@cryptopro.ru 1190 o Lidia Nikiforova 1191 CryptoPro 1192 nikiforova@cryptopro.ru 1194 Appendix C. Acknowledgments 1196 Authors' Addresses 1198 Stanislav Smyshlyaev (editor) 1199 CryptoPro 1200 18, Suschevsky val 1201 Moscow 127018 1202 Russian Federation 1204 Phone: +7 (495) 995-48-20 1205 Email: svs@cryptopro.ru 1206 Evgeny Alekseev 1207 CryptoPro 1208 18, Suschevsky val 1209 Moscow 127018 1210 Russian Federation 1212 Email: alekseev@cryptopro.ru 1214 Ekaterina Griboedova 1215 CryptoPro 1216 18, Suschevsky val 1217 Moscow 127018 1218 Russian Federation 1220 Email: griboedova.e.s@gmail.com 1222 Alexandra Babueva 1223 CryptoPro 1224 18, Suschevsky val 1225 Moscow 127018 1226 Russian Federation 1228 Email: babueva@cryptopro.ru