]>
GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
CryptoPro
18, Suschevsky val
Moscow
127018
Russian Federation
+7 (495) 9954820
svs@cryptopro.ru
CryptoPro
18, Suschevsky val
Moscow
127018
Russian Federation
alekseev@cryptopro.ru
CryptoPro
18, Suschevsky val
Moscow
127018
Russian Federation
griboedova.e.s@gmail.com
CryptoPro
18, Suschevsky val
Moscow
127018
Russian Federation
babueva@cryptopro.ru
CryptoPro
18, Suschevsky val
Moscow
127018
Russian Federation
nikiforova@cryptopro.ru
General
Network Working Group
GOST, cipher suite, TLS 1.3, signature scheme
The purpose of this document is to make the Russian cryptographic standards
available to the Internet community for their implementation in the Transport Layer Security (TLS)
Protocol Version 1.3.
This specification defines four new cipher suites, seven new signature schemes
and a key exchange mechanism for the TLS 1.3 protocol, that are based on Russian cryptographic standards (called GOST algorithms).
Additionally, this document specifies a profile of TLS 1.3 with GOST algorithms so that implementers can produce interoperable
implementations. This document does not imply IETF endorsement of the cipher suites, signature schemes key exchange mechanism.
Introduction
This document defines four new cipher suites (the TLS13_GOST cipher suites) and seven new signature schemes (the TLS13_GOST signature schemes)
for the Transport Layer Security (TLS) Protocol Version 1.3, that are based on Russian cryptographic standards
GOST R 34.122015 , GOST R 34.112012 and GOST R 34.102012 .
The TLS13_GOST cipher suites (see ) have the following values:

TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03};
TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04};
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05};
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}.
Each TLS13_GOST cipher suite specifies a pair (record protection algorithm, hash algorithm) such that:

The record protection algorithm is the AEAD algorithm (see ) based on the GOST R 34.122015 block cipher
in the Multilinear Galois Mode (MGM) and the external rekeying approach
(see ) intended for increasing the lifetime of symmetric keys used to protect records.

The hash algorithm is the GOST R 34.112012 algorithm .
Note: The TLS13_GOST cipher suites are divided into two types (depending on the key lifetime limitations, see and
): the "_S" (strong) cipher suites and the "_L" (light) cipher suites.
The TLS13_GOST signature schemes have the following values:

gostr34102012_256a = 0x0709;

gostr34102012_256b = 0x070A;

gostr34102012_256c = 0x070B;

gostr34102012_256d = 0x070C;

gostr34102012_512a = 0x070D;

gostr34102012_512b = 0x070E;

gostr34102012_512c = 0x070F.
Each TLS13_GOST signature scheme specifies a pair (signature algorithm, elliptic curve) such that:

The signature algorithm is the GOST R 34.102012 algorithm .

The elliptic curve is one of the curves defined in .
Also, this document specifies the key exchange mechanism with GOST algorithms for TLS 1.3 protocol (see ).
Additionally, this document specifies a TLS13_GOST profile of the TLS 1.3 protocol with GOST algorithms so that implementers can produce interoperable implementations.
It uses TLS13_GOST cipher suites, TLS13_GOST signature schemes, key exchange mechanism that defined in this document.
Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted
as described in BCP 14 when, and only when,
they appear in all capitals, as shown here.
Basic Terms and Definitions
This document uses the following terms and definitions for the sets and operations
on the elements of these sets:
 B_t

the set of byte strings of length t, t >= 0, for t = 0 the
B_t set consists of a single empty string of zero length.
If A is an element of B_t, then A = (a_1, a_2,
... , a_t), where a_1, a_2, ... , a_t are in {0, ... , 255};
 B*

the set of all byte strings of a finite length
(hereinafter referred to as strings), including the empty
string;
 A[i..j]

the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in B_{ji+1}, where A = (a_1, a_2, ... , a_t) in B_t and 1<=i<=j<=t;
 A[i]

the integer a_i in {0, ... , 255}, where A = (a_1, a_2, ... , a_t) in B_t and 1<=i<=t;
 A

the length of the byte string A in bytes;
 A  C

the concatenation of strings A and C both belonging to B*, i.e.,
a string in B_{A+C}, where the left substring in
B_A is equal to A, and the right substring in B_C is
equal to C;
 i & j

bitwise AND of integers i and j;
 STR_t

the byte string STR_t(i) = (i_1, ... , i_t) in B_t corresponding to
an integer i = 256^{t1} * i_1 + ... + 256 * i_{t1} + i_t
(the interpretation of the integer as a byte string in bigendian format);
 str_t

the byte string str_t(i) = (i_1, ... , i_t) in B_t corresponding to
an integer i = 256^{t1} * i_t + ... + 256 * i_2 + i_1
(the interpretation of the integer as a byte string in littleendian format);
 k

the length of the block cipher key in bytes;
 n

the length of the block cipher block in bytes;
 IVlen

the length of the initialization vector in bytes;
 S

the length of the authentication tag in bytes;
 E_i

the elliptic curve indicated by client in "supported_groups" extension;
 O_i

the zero point of the elliptic curve E_i;
 m_i

the order of group of points belonging to the elliptic curve E_i;
 q_i

the cyclic subgroup order of group of points belonging to the elliptic curve E_i;
 h_i

the cyclic subgroup cofactor which is equal to m_i / q_i;
 Q_sign

the public key stored in endpoint's certificate;
 d_sign

the private key that corresponds to the Q_sign key;
 P_i

the point of the elliptic curve E_i of the order q_i;
 (d_C^i, Q_C^i)

the client's ephemeral key pair which consists of the private key and the public key corresponding to the elliptic curve E_i;
 (d_S^i, Q_S^i)

the server's ephemeral key pair which consists of the private key and the public key corresponding to the elliptic curve E_i.
Cipher Suite Definition
The cipher suite value is used to indicate a record protection algorithm and a hash algorithm which an endpoint supports (see Section 4.1.2 of ).
This section defines the following four TLS13_GOST cipher suites that can be used to support Russian cryptographic algorithms:
Each cipher suite specifies a pair of the record protection algorithm (see ) and the hash algorithm ().
Record Protection Algorithm
In accordance with Section 5.2 of the record protection algorithm translates a TLSPlaintext structure into a TLSCiphertext structure.
If TLS13_GOST cipher suite is negotiated, the encrypted_record field of the TLSCiphertext structure MUST be set to the AEADEncrypted value computed as follows:

AEADEncrypted = AEADEncrypt(sender_record_write_key, nonce, additional_data, plaintext),
where

the AEADEncrypt function is defined in ;

the sender_record_write_key is derived from the sender_write_key (see Section 7.3 of ) using
TLSTREE function defined in and sequence number seqnum as follows:

sender_record_write_key = TLSTREE(sender_write_key, seqnum);

the nonce value is derived from the record sequence number seqnum and the sender_write_iv value (see Section 7.3
of ) in accordance with Section 5.3 of ;

the additional_data value is the record header that is generated in accordance with Section 5.2 of ;

the plaintext value is the TLSInnerPlaintext structure encoded in accordance with Section 5.2 of .
Note1: The AEADEncrypt function is exactly the same as the AEADEncrypt function defined in except the key
(the first argument) is calculated from the sender_write_key and sequence number seqnum for each message separately to support external
rekeying approach according to .
Note2: The record sequence number is the value in the range 0SNMAX, where the SNMAX value is defined in .
The SNMAX parameter is specified by the particular TLS13_GOST cipher suite to limit the amount of data that can be encrypted under
the same traffic key material (sender_write_key, sender_write_iv).
The record deprotection algorithm reverses the process of the record protection. In order to decrypt and verify the protected record with sequence number
seqnum the algorithm takes as input the sender_record_write_key is derived from the sender_write_key, nonce, additional_data and the AEADEncrypted value
and outputs the res value which is either the plaintext or an error indicating that the decryption failed.
If TLS13_GOST cipher suite is negotiated, the res value MUST be computed as follows:

res = AEADDecrypt(sender_record_write_key, nonce, additional_data, AEADEncrypted),
where the AEADDecrypt function is defined in .
Note: The AEADDecrypt function is exactly the same as the AEADDecrypt function defined in except the key
(the first argument) is calculated from the sender_write_key and sequence number seqnum for each message separately to support external
rekeying approach according to .
AEAD Algorithm
The AEADEncrypt and AEADDecrypt functions are defined as follows.
= 0, 
  plaintext P in B_t, t >= 0. 
 Output: 
  ciphertext C in B_{P}, 
  authentication tag T in B_S. 

 1. MGMnonce = STR_1(nonce[1] & 0x7f)  nonce[2..IVlen]; 
 2. (MGMnonce, A, C, T) = MGMEncrypt(K, MGMnonce, A, P); 
 3. Return C  T. 
++
++
 AEADDecrypt(K, nonce, A, C  T) 

 Input: 
  encryption key K in B_k, 
  unique vector nonce in B_IVlen, 
  additional authenticated data A in B_r, r >= 0, 
  ciphertext C in B_t, t >= 0, 
  authentication tag T in B_S. 
 Output: 
  plaintext P in B_{C} or FAIL. 

 1. MGMnonce = STR_1(nonce[1] & 0x7f)  nonce[2..IVlen]; 
 2. res' = MGMDecrypt(K, MGMnonce, A, C, T); 
 3. IF res' = FAIL then return FAIL; 
 4. IF res' = (A, P) then return P. 
++
]]>
where

MGMEncrypt and MGMDecrypt functions are defined in . The size of the authentication tag T is equal to n bytes (S = n).
The size of the nonce parameter is equal to n bytes (IVlen = n).
The cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik
as a base block cipher for the AEAD algorithm. The block length n is 16 bytes (n = 16) and the key length k is 32 bytes (k = 32).
The cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST use Magma
as a base block cipher for the AEAD algorithm. The block length n is 8 bytes (n = 8) and the key length k is 32 bytes (k = 32).
TLSTREE
The TLS13_GOST cipher suites use the TLSTREE function for the external rekeying approach (see ). The TLSTREE function is defined as follows:

TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8(i & C_1)), STR_8(i & C_2)), STR_8(i & C_3)),
where

K_root in B_32;

i in {0, 1, ... , 2^64  1};

KDF_j(K, D), j = 1, 2, 3, is the key derivation function defined as follows:
KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D),
KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D),
KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D),
where the KDF_GOSTR3411_2012_256 function is defined in , K in B_32, D in B_8.

C_1, C_2, C_3 are constants defined by the particular cipher suite as follows:
SNMAX parameter
The SNMAX parameter is the maximum number of records encrypted under the same traffic key material (sender_write_key and sender_write_iv)
and is defined by the particular cipher suite as follows:
Hash Algorithm
The Hash algorithm is used for key derivation process (see Section 7.1 of ),
Finished message calculation (see Section 4.4.4 of ), TranscriptHash function computation
(see Section 4.4.1 of ), PSK binder value calculation (see Section 4.2.11.2 of ),
external rekeying approach (see ) and other purposes.
In case of negotiating a TLS13_GOST cipher suite the Hash algorithm MUST be the GOST R 34.112012
hash algorithm with 32byte (256bit) hash value.
Signature Scheme Definition
The signature scheme value is used to indicate a single signature algorithm and a curve that can be used in digital signature (see Section 4.2.3 of ).
This section defines the following seven TLS13_GOST signature schemes that can be used to support Russian cryptographic algorithms:
One of the TLS13_GOST signature schemes listed above SHOULD be used with the TLS13_GOST profile.
Each signature scheme specifies a pair of the signature algorithm (see ) and the elliptic curve (see ).
The procedure to calculate the signature value using TLS13_GOST signature schemes is defined in .
Signature Algorithm
Signature algorithms corresponding to the TLS13_GOST signature schemes are defined as follows:
Elliptic Curve
Elliptic curves corresponding to the TLS13_GOST signature schemes are defined as follows:
SIGN function
If TLS13_GOST signature scheme is used, the signature value in CertificateVerify message (see )
MUST be calculated using the SIGN function defined as follows:
where

q is the subgroup order of group of points of the elliptic curve;

l is defined as follows:

l = 32 for gostr34102012_256a, gostr34102012_256b, gostr34102012_256c
and gostr34102012_256d signature schemes;

l = 64 for gostr34102012_512a, gostr34102012_512b and gostr34102012_512c
signature schemes;

SIGNGOST is an algorithm which takes as an input private key d_sign and message M and returns a pair of integers (r, s)
calculated during signature generation process in accordance with the GOST R 34.102012 signature algorithm
(see Section 6.1 of ).
Note: The signature value sgn is the concatenation of two strings that are byte representations of r and s values in the littleendian format.
Key Exchange and Authentication
Key exchange and authentication process in case of using TLS13_GOST profile is defined in
, and .
Key Exchange
TLS13_GOST profile support three basic key exchange modes which are defined in : ECDHE, PSKonly and PSKwithECDHE.
Note: In accordance with TLS 1.3 also supports key exchange modes based on DiffieHellman protocol
over finite fields. However, TLS13_GOST cipher suites MUST use only modes based on DiffieHellman protocol over elliptic curves.
In accordance with PSKs can be divided into two types:

internal PSKs which can be established during the previous connection;

external PSKs which can be established out of band.
If TLS13_GOST profile is used, PSKonly key exchange mode SHOULD be established only via the internal PSKs, and external PSKs
SHOULD be used only in PSKwithECDHE mode (see more in ).
If TLS13_GOST profile is used and ECDHE or PSKwithECDHE key exchange mode is used the ECDHE shared secret value should be calculated
in accordance with on the basis of one of the elliptic curves defined in .
ECDHE Shared Secret Calculation
If TLS13_GOST profile is used, ECDHE shared secret value should be calculated in accordance with
and . The public ephemeral keys used to obtain ECDHE shared secret value should be represented in format
described in .
ECDHE Shared Secret Calculation on Client Side
The client calculates ECDHE shared secret value in accordance with the following steps:
1. Chooses from all supported curves E_1, ..., E_R the set of curves E_{i_1}, ..., E_{i_r}, 1 <= i_1 <= i_r <= R, where

r >= 1 in the case of the first ClientHello message;

r = 1 in the case of responding to HelloRetryRequest message, E_{i_1} corresponds to the curve
indicated in the "key_share" extension in the HelloRetryRequest message.
2. Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ..., (d_C^{i_r}, Q_C^{i_r}) corresponding to
the curves E_{i_1}, ..., E_{i_r}, where for each i in {i_1, ..., i_r}:

d_C^i is chosen from {1, ..., q_i  1} at random;

Q_C^i = d_C^i * P_i.
3. Sends ClientHello message specified in accordance with Section 4.1.2 of
and , which contains:

"key_share" extension with public ephemeral keys Q_C^{i_1}, ..., Q_C^{i_r} generated in accordance with
Section 4.2.8 of ;

"supported_groups" extension with supported curves E_1, ..., E_R generated in accordance with
Section 4.2.7 of .
Note: Client MAY send an empty "key_share" extension in the first ClientHello in order to request group
selection from the server in the HelloRetryRequest message and to generate ephemeral key for the selected group only.
The ECDHE value may be calculated without sending HelloRetryRequest, if the "key_share" extension in the first
ClientHello message consists the value corresponded to the curve that will be selected by the server.
4. In case of receiving HelloRetryRequest message client MUST return to step 1 and correct parameters in accordance
with Section 4.1.2 of .
In case of receiving ServerHello message client proceeds to the next step. In other cases client MUST terminate the
connection with "unexpected_message" alert.
5. Extracts curve E_res and ephemeral key Q_S^res, res in {1, ..., R}, from ServerHello message and checks whether
the Q_S^res belongs to E_res. If this check fails, the client MUST abort the handshake with "handshake_failure" alert.
6. Generates Q^ECDHE:

Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) * Q_S^res.
7. Client MUST check whether the computed shared secret Q^ECDHE is not equal to the zero point O_res. If this check fails,
the client MUST abort the handshake with "handshake_failure" alert.
8. Shared secret value ECDHE is the byte representation of the coordinate X^ECDHE of point Q^ECDHE in the littleendian format:

ECDHE = str_{coordinate_length}(X^ECDHE),
where the coordinate_length value is defined by the particular elliptic curve (see ).
ECDHE Shared Secret Calculation on Server Side
Upon receiving the ClientHello message, the server calculates ECDHE shared secret value in accordance with the following steps:
1. Chooses the curve E_res, res in {1, ..., R}, from the list of the curves E_1, ..., E_R indicated in "supported_groups"
extension in ClientHello message and the corresponding public ephemeral key value Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r},
1 <= i_1 <= i_r <= R, indicated in "key_share" extension. If no corresponding public ephemeral key value is found
(res in {1, ..., R}\{i_1, ..., i_r}), server MUST send HelloRetryRequest message with "key_share" extension indicating the selected
elliptic curve E_res and wait for the new ClientHello message.
2. Checks whether Q_C^res belongs to E_res. If this check fails, the server MUST abort the handshake with "handshake_failure" alert.
3. Generates ephemeral key pair (d_S^res, Q_S^res) corresponding to E_res:

d_S^res is chosen from {1, ..., q_res  1} at random;

Q_S^res = d_S^res * P_res.
4. Sends ServerHello message generated in accordance with Section 4.1.3 of
and with "key_share" extension which contains public ephemeral key
value Q_S^res corresponding to E_res.
5. Generates Q^ECDHE:

Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res.
6. Server MUST check whether the computed shared secret Q^ECDHE is not equal to the zero point O_res. If this check fails, the server MUST
abort the handshake with "handshake_failure" alert.
7. Shared secret value ECDHE is the byte representation of the coordinate X^ECDHE of point Q^ECDHE in the littleendian format:

ECDHE = str_{coordinate_length}(X^ECDHE),
where the coordinate_length value is defined by the particular elliptic curve (see ).
Public ephemeral key representation
This section defines the representation format of the public ephemeral keys generated during ECDHE shared secret calculation
(see and ).
If TLS13_GOST profile is used and ECDHE or PSKwithECDHE key exchange mode is used, the public ephemeral key Q
indicated in the KeyShareEntry.key_exchange field MUST contain the data defined by the following structure:
where X and Y, respectively, contain the byte representations of the x and the y values of point Q (Q = (x, y)) in the littleendian format
and are specified as follows:

X = str_{coordinate_length}(x);

Y = str_{coordinate_length}(y).
The coordinate_length value is defined by the particular elliptic curve (see ).
Values for the TLS Supported Groups Registry
The "supported_groups" extension is used to indicate the set of the elliptic curves supported by an endpoint and is defined
in Section 4.2.7 . This extension is always contained in ClientHello message and optionally
in EncryptedExtensions message.
This section defines the following seven elliptic curves that can be used to support Russian cryptographic algorithms:
If TLS13_GOST profile is used and ECDHE or PSKwithECDHE key exchange mode is established, one of the elliptic curves listed above SHOULD be used.
Each curve corresponds to the particular identifier and specifies the value of coordinate_length parameter (see "cl" column) as follows:
Note: The identifier values and the corresponding elliptic curves are the same as in .
Authentication
In accordance with authentication can happen via signature with certificate or via symmetric preshared key (PSK).
The server side of the channel is always authenticated; the client side is optionally authenticated.
PSKbased authentication happens as a side effect of key exchange. If TLS13_GOST profile is used, external PSKs SHOULD be combined
only with the mutual authentication (see more in ).
Certificatebased authentication happens via Authentication messages and optional CertificateRequest message (sent if client authentication is required).
In case of using TLS13_GOST profile the signature schemes used for certificatebased authentication are defined in
and the Authentication messages are specified in and . The CertificateRequest message is specified in .
Handshake Messages
The TLS13_GOST profile specify the ClientHello, ServerHello, CertificateRequest, Certificate
and CertificateVerify handshake messages that are described in further detail below.
Hello Messages
The ClientHello message is sent when a client first connects to a server or responds
to a HelloRetryRequest message and is specified in accordance with Section 4.1.2 of .
In case of using the TLS13_GOST profile, the ClientHello message MUST meet the following requirements.

The ClientHello.cipher_suites field MUST contain the values defined in .

If server authentication via a certificate is required, the extension_data field
of the "signature_algorithms" extension MUST contain the values defined in ,
which correspond to the GOST R 34.102012 signature algorithm.

If server authentication via a certificate is required and the client uses optional
"signature_algorithms_cert" extension, the extension_data field of this extension SHOULD contain the
values defined in , which correspond to the GOST R 34.102012 signature algorithm.

If client wants to establish TLS 1.3 connection using ECDHE shared secret value, the extension_data field
of the "supported_groups" extension MUST contain the elliptic curve identifiers defined
in .
The ServerHello message is sent by the server in response to a ClientHello message to negotiate
an acceptable set of handshake parameters based on the ClientHello and is specified in accordance
with Section 4.1.3 of .
In case of using the TLS13_GOST profile, the ServerHello message MUST meet the following requirements.

The ServerHello.cipher_suite field MUST contain one of the values defined
in .

If server decides to establish TLS 1.3 connection using ECDHE shared secret value,
the extension_data field of the "key_share" extension MUST contain the elliptic curve
identifier and the public ephemeral key that satisfy the following conditions.

The elliptic curve identifier corresponds to a value that was provided in the
"supported_groups" and the "key_share" extensions in the ClientHello message.

The elliptic curve identifier is one of the values defined in .

The public ephemeral key corresponds to the elliptic curve specified by the
KeyShareEntry.group identifier.
CertificateRequest
This message is sent when server requests client authentication via a certificate and is specified in
accordance with Section 4.3.2 of .
In case of using the TLS13_GOST profile, the CertificateRequest message MUST meet the following
requirements.

The extension_data field of the "signature_algorithms" extension MUST contain only the values
defined in .

If server uses optional "signature_algorithms_cert" extension, the extension_data field
of this extension SHOULD contain only the values defined in .
Certificate
This message is sent to convey the endpoint's certificate chain to the peer and is specified in
accordance with Section 4.4.2 of .
In case of using the TLS13_GOST profile, the Certificate message MUST meet the following requirements.

Each endpoint's certificate provided to the peer MUST be signed using the algorithm
which corresponds to a signature scheme indicated by the peer in its "signature_algoritms_cert"
extension, if present (or in the "signature_algorithms" extension, otherwise).

The signature algorithm used for signing certificates SHOULD correspond to the one of the
signature schemes defined in .
CertificateVerify
This message is sent to provide explicit proof that an endpoint possesses the private key
corresponding to the public key indicated in its certificate and is specified in accordance
with Section 4.4.3 of .
In case of using the TLS13_GOST profile, the CertificateVerify message MUST meet the following requirements.

The CertificateVerify.algorithm field MUST contain the signature scheme identifier which
corresponds to the value indicated in the peer's "signature_algorithms" extension and
which is one of the values defined in .

The CertificateVerify.signature field contains the sgn value, which is computed as follows:

where

the SIGN function is defined in ,

d_sign is the sender longterm private key that corresponds to
the sender longterm public key Q_sign from the sender's certificate,

the message M is defined in accordance with Section 4.4.3 of .
IANA Considerations
IANA has added numbers {0xC1, 0x03}, {0xC1, 0x04}, {0xC1, 0x05} and {0xC1, 0x06} with the names
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L,
TLS_GOSTR341112_256_WITH_MAGMA_MGM_L,
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S,
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S to
the "TLS Cipher Suites" registry with this document as reference, as shown below.
IANA has added numbers 0x0709, 0x070A, 0x070B, 0x070C, 0x070D, 0x070E and 0x070F with the names
gostr34102012_256a,
gostr34102012_256b,
gostr34102012_256c,
gostr34102012_256d,
gostr34102012_512a,
gostr34102012_512b,
gostr34102012_512c
to the "TLS SignatureScheme" registry, as shown below.
Historical considerations
Due to historical reasons in addition to the curve identifier values listed in Table 5
there exist some additional identifier values that correspond to
the signature schemes as follows.
Client should be prepared to handle any of them correctly if corresponding signature scheme is included in the "signature_algorithms"
or "signature_algorithms_cert" extensions.
Security Considerations
In order to create an effective implementation client and server SHOULD follow the rules below.
1. While using TLSTREE algorithm function KDF_j, j = 1, 2, 3, SHOULD be invoked only if the record sequence number seqnum reaches such a value that

seqnum & C_j != (seqnum  1) & C_j.
Otherwise the previous value should be used.
2. For each preshared key value PSK the binder_key value should be computed only once within all connections where ClientHello message contains a
"pre_shared_key" extension indicating this PSK value.
In order to ensure the secure TLS 1.3 connection client and server SHOULD fulfil the following requirements.
1. An internal PSK value is NOT RECOMMENDED to be used to establish more than one TLS 1.3 connection.
2. 0RTT data SHOULD NOT be sent during TLS 1.3 connection. The reasons for this restriction are that the 0RTT data is not forward secret and
is not resistant to replay attacks (see more in Section 2.3 of ).
3. If client authentication is required, server SHOULD NOT send Application Data, NewSessionTicket and KeyUpdate messages
prior to receiving the client's Authentication messages since any data sent at that point is
being sent to an unauthenticated peer.
4. External PSKs SHOULD be used only in PSKwithECDHE mode. In case of using external PSK in PSKonly mode the attack described in
is possible which leads to the situation when client establishes connection to itself. One of the mitigations proposed in is to use
certificates, however, in that case, an impersonation attack as in occurs.
If the connections are established with additional usage
of key_share extension (in PSKwithECDHE mode), then the adversary which just echoes messages cannot reveal the traffic
key material (as long as the used group is secure).
5. In case of using external PSK, the mutual authentication MUST be provided by the external PSK distribution mechanism between the endpoints
which guarantees that the derived external PSK is unknown to anyone but the endpoints. In addition, the endpoint roles (i.e. client and server)
MUST be fixed during this mechanism and each role can match only to one endpoint during the whole external PSK lifetime.
References
Normative References
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
GOST R 34.122015: Block Cipher "Kuznyechik"
This document is intended to be a source of information about the Russian Federal standard GOST R 34.122015 describing the block cipher with a block length of n=128 bits and a key length of k=256 bits, which is also referred to as "Kuznyechik". This algorithm is one of the set of Russian cryptographic standard algorithms (called GOST algorithms).
GOST R 34.112012: Hash Function
This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.112012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831.
GOST R 34.102012: Digital Signature Algorithm
This document provides information about the Russian Federal standard for digital signatures (GOST R 34.102012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.102012 regarding digital signature generation and verification. This document updates RFC 5832.
Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.102012 and GOST R 34.112012
The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST R 34.102012 and GOST R 34.112012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.
These specifications define the pseudorandom functions, the key agreement algorithm based on the DiffieHellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
Rekeying Mechanisms for Symmetric Keys
A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of rekeying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM, CBC, CFB, and OMAC.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
GOST R 34.122015: Block Cipher "Magma"
In addition to a new cipher with a block length of n=128 bits (referred to as "Kuznyechik" and described in RFC 7801), Russian Federal standard GOST R 34.122015 includes an updated version of the block cipher with a block length of n=64 bits and key length of k=256 bits, which is also referred to as "Magma". The algorithm is an updated version of an older block cipher with a block length of n=64 bits described in GOST 2814789 (RFC 5830). This document is intended to be a source of information about the updated version of the 64bit cipher. It may facilitate the use of the block cipher in Internet applications by providing information for developers and users of the GOST 64bit cipher with the revised version of the cipher for encryption and decryption.
Multilinear Galois Mode (MGM)
Multilinear Galois Mode (MGM) is an Authenticated Encryption with Associated Data (AEAD) block cipher mode based on the EncryptthenMAC (EtM) principle. MGM is defined for use with 64bit and 128bit block ciphers.
MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g., TLS 1.3 and IPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher.
GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2
CryptoPro
Cryptocom
Independent Consultant
CryptoPro
Informative References
Selfie: reflections on TLS 1.3 with PSK
University of Haifa
Amazon
Continuing to reflect on TLS 1.3 with external PSK
CryptoPro
CryptoPro
CryptoPro
CryptoPro
Test Examples
Test case
Test examples are given for the following order of using the TLS_GOST profile for the TLS 1.3 protocol.
1. Full TLS Handshake is used.
2. ECDHE key exchange mode is used.
The elliptic curve GC512C is used for ECDHE shared secret calculation.
3. The server side only authentication is used.
The signature scheme gost34102012_256b (0x070A) is used.
4. TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S cipher suite is negotiated.
5. Application Data is sent prior to sending the Finished message by client.
6. NewSessionTicket is sent after establishing a secure connection.
7. Four records of the Application data type are sent during the operation of the Record protocol.
8. Alert protocol is used for closure of the connection.
Contributors

Lilia Akhmetzyanova
CryptoPro
lah@cryptopro.ru

Alexandr Sokolov
CryptoPro
sokolov@cryptopro.ru

Vasily Nikolaev
CryptoPro
nikolaev@cryptopro.ru