| Network Working Group | S. Smyshlyaev, Ed. |
| Internet-Draft | E. Alekseev |
| Intended status: Informational | E. Smyshlyaeva |
| Expires: May 2, 2020 | A. Babueva |
| CryptoPro | |
| October 30, 2019 |
GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
draft-smyshlyaev-tls13-gost-suites-00
This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol Version 1.3 to support the Russian cryptographic standard algorithms.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document specifies four new cipher suites for the Transport Layer Security (TLS) Protocol Version 1.3 [RFC8446] to support the set of Russian cryptographic standard algorithms called GOST algorithms (see Section 4). These cipher suites use the hash algorithm GOST R 34.11-2012 [GOST3411-2012] (the English version can be found in [RFC6986]), the AEAD algorithm MGM [DraftMGM] and the block ciphers GOST R 34.12-2015 [GOST3412-2015] (the English version can be found in [RFC7801]). The GOST cipher suites have the following values:
These cipher suites have different key lifetime value (see [RFC8645]), so they are divided into two types: the _S (strong) cipher suites and the _L (light) cipher suites (see Section 4.1.1.3, Section 4.1.1.2).
This document specifies seven new signature schemes (see Section 5) to be used with GOST cipher suites. These signature schemes use the signature algorithm GOST R 34.10-2012 [GOST3410-2012] (the English version can be found in [RFC7091]) and have the following values:
Additionally this document specifies the key exchange and authentication process in case of negotiating GOST cipher suites (see Section 6).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document uses the following terms and definitions for the sets and operations on the elements of these sets:
This document defines the following new values for the "Cipher Suites" registry, that can be used in the ClientHello.cipher_suites and ServerHello.cipher_suites fields for the particular cipher suite:
CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = TBD1;
CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = TBD2;
CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = TBD3;
CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = TBD4;
Each cipher suite defines the pair of the AEAD algorithm and the hash algorithm. AEAD algorithm is used for the payload protection (see Section 4.1 for more details) and hash algorithm is used for key derivation and handshake message authentication.
All of the cipher suites described in this document use the block cipher in Authenticated Encryption with Associated Data (AEAD) mode (see Section 4.1.1) to protect records. The TLSCiphertext structure is specified in accordance with [RFC8446] as follows.
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /*TLSv1.2*/
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
The encrypted_record field of TLSCiphertext is set to AEADEncrypted, where AEADEncrypted is computed as follows:
where
additional_data = TLSCiphertext.opaque_type ||
TLSCiphertext.legacy_record_version ||
TLSCiphertext.length;
In order to decrypt and verify, the cipher takes as input the key, nonce, additional data and the AEADEncrypted value. The output is either the plaintext or an error indicating that the decryption failed.
where AEAD-Decrypt function is defined in Section 4.1.1.
The GOST cipher suites use the block cipher in MGM authenticated encryption with associated data mode defined in [DraftMGM]. The base block cipher is defined in Section 4.1.1.1. The size S of the authentication field is n bytes. The IVlen parameter is n bytes.
The record key material is a key material that is generated from the traffic key material and is used to protect a record with the certain sequence number. All of the cipher suites described in this document use TLSTREE algorithm to derive record key material (Section 4.1.1.2).
For each record with sequence number seqnum AEAD-Encrypt and AEAD-Decrypt functions are defined as follows.
+-------------------------------------------------------------------+
| AEAD-Encrypt(K, nonce, A, P) |
|-------------------------------------------------------------------|
| Input: |
| - encryption key K in B_k, |
| - unique vector nonce in B_IVlen, |
| - additional authenticated data A in B_s, s >= 0, |
| - plaintext P in B_s, s >= 0. |
| Output: |
| - ciphertext C in B_{|P|}, |
| - authentication tag T T in B_S. |
|-------------------------------------------------------------------|
| 1. K^seqnum = TLSTREE(K, seqnum) |
| 2. MGMnonce = nonce[1..1] & 0x7f | nonce[2..IVlen] |
| 3. (MGMnonce, A, C, T) = MGM-Encrypt(K^seqnum, MGMnonce, A, P) |
| 4. Return C | T. |
+-------------------------------------------------------------------+
+-------------------------------------------------------------------+
| AEAD-Decrypt(K, nonce, A, C | T) |
|-------------------------------------------------------------------|
| Input: |
| - encryption key K in B_k, |
| - unique vector nonce in B_IVlen, |
| - additional authenticated data A in B_s, s >= 0, |
| - ciphertext C in B_s, s >= 0 |
| - authentication tag T in B_S. |
| Output: |
| - plaintext P in B_{|C|} or FAIL. |
|-------------------------------------------------------------------|
| 1. K^seqnum = TLSTREE(K, seqnum) |
| 2. MGMnonce = nonce[1..1] & 0x7f | nonce[2..IVlen] |
| 3. res' = MGM-Decrypt(K^seqnum, MGMnonce, A, C, T) |
| 4. IF res' = FAIL then return FAIL; else return P. |
+-------------------------------------------------------------------+
MGM-Encrypt and MGM-Decrypt functions are defined in [DraftMGM], TLSTREE function is defined in Section 4.1.1.2. The maximum value of the sequence number seqnum during one TLS 1.3 connection is defined in Section 4.1.1.3.
The cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik [RFC7801] as a base block cipher for the AEAD algorithm. The block length n is 16 bytes and the key length k is 32 bytes.
The cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST uses Magma [GOST3412-2015] as a base block cipher for the AEAD algorithm. The block length n is 8 bytes and the key length k is 32 bytes.
The GOST cipher suites use the TLSTREE function for the external re-keying approach (see [RFC8645]). The TLSTREE function is defined as follows:
where
+------------------------------------------+----------------------+
| CipherSuites | C_1, C_2, C_3 |
+------------------------------------------+----------------------+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L |C_1=0xf800000000000000|
| |C_2=0xfffffff000000000|
| |C_3=0xffffffffffffe000|
+------------------------------------------+----------------------+
|TLS_GOSTR341112_256_WITH_MAGMA_MGM_L |C_1=0xffe0000000000000|
| |C_2=0xffffffffc0000000|
| |C_3=0xffffffffffffff80|
+------------------------------------------+----------------------+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S |C_1=0xffffffffe0000000|
| |C_2=0xffffffffffff0000|
| |C_3=0xfffffffffffffff8|
+------------------------------------------+----------------------+
|TLS_GOSTR341112_256_WITH_MAGMA_MGM_S |C_1=0xfffffffffc000000|
| |C_2=0xffffffffffffe000|
| |C_3=0xffffffffffffffff|
+------------------------------------------+----------------------+
Table 1
The SNMAX parameter defines the maximal value of the sequence number seqnum during one TLS 1.3 connection and is defined as follows:
+------------------------------------------+--------------------+
| CipherSuites | SNMAX |
+------------------------------------------+--------------------+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L | SNMAX = 2^64 - 1 |
+------------------------------------------+--------------------+
|TLS_GOSTR341112_256_WITH_MAGMA_MGM_L | SNMAX = 2^64 - 1 |
+------------------------------------------+--------------------+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S | SNMAX = 2^42 - 1 |
+------------------------------------------+--------------------+
|TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | SNMAX = 2^39 - 1 |
+------------------------------------------+--------------------+
Table 2
The function HASH for all the cipher suites defined in this document is the GOST R 34.11-2012 [RFC6986] hash algorithm with 32-byte (256-bit) hash code.
The function HASH is used for key derivation process (see Section 7.1 of [RFC8446]), Finished message calculation, Transcript-Hash function, PSK binder value calculation, derivation of record key material (see Section 4.1.1.2) and other purposes during key exchange process.
The signature scheme values are used to indicate to the server/client which signature algorithms and curves can be used in digital signatures and are defined by the SignatureSchemeList structure (see Section 4.2.3 of [RFC8446]) as follows:
struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;
This document defines new values for the "SignatureAlgorithm" registry that can be used in the SignatureSchemeList.supported_signature_algorithms field for the particular signature scheme:
enum {
gostr34102012_256a(TBD5),
gostr34102012_256b(TBD6),
gostr34102012_256c(TBD7),
gostr34102012_256d(TBD8),
gostr34102012_512a(TBD9),
gostr34102012_512b(TBD10),
gostr34102012_512c(TBD11)
} SignatureScheme;
where the values correspond to the following signature algorithms and curves:
+------------------+--------------------------------------+--------+
| SignatureScheme | Signature Algorithm | Refe- |
| Value | | rences |
+------------------+--------------------------------------+--------+
|gostr34102012_256a|GOST R 34.10-2012 + 32-byte key length|RFC 7091|
+------------------+--------------------------------------+--------+
|gostr34102012_256b|GOST R 34.10-2012 + 32-byte key length|RFC 7091|
+------------------+--------------------------------------+--------+
|gostr34102012_256c|GOST R 34.10-2012 + 32-byte key length|RFC 7091|
+------------------+--------------------------------------+--------+
|gostr34102012_256d|GOST R 34.10-2012 + 32-byte key length|RFC 7091|
+------------------+--------------------------------------+--------+
|gostr34102012_512a|GOST R 34.10-2012 + 64-byte key length|RFC 7091|
+------------------+--------------------------------------+--------+
|gostr34102012_512b|GOST R 34.10-2012 + 64-byte key length|RFC 7091|
+------------------+--------------------------------------+--------+
|gostr34102012_512c|GOST R 34.10-2012 + 64-byte key length|RFC 7091|
+------------------+--------------------------------------+--------+
Table 3
+------------------+--------------------------------------+--------+
| SignatureScheme | Curve Identifier Value | Refe- |
| Value | | rences |
+------------------+--------------------------------------+--------+
|gostr34102012_256a| id-tc26-gost-3410-2012-256-paramSetA |RFC 7836|
+------------------+--------------------------------------+--------+
|gostr34102012_256b|id-GostR3410-2001-CryptoPro-A-ParamSet|RFC 4357|
+------------------+--------------------------------------+--------+
|gostr34102012_256c|id-GostR3410-2001-CryptoPro-B-ParamSet|RFC 4357|
+------------------+--------------------------------------+--------+
|gostr34102012_256d|id-GostR3410-2001-CryptoPro-C-ParamSet|RFC 4357|
+------------------+--------------------------------------+--------+
|gostr34102012_512a| id-tc26-gost-3410-12-512-paramSetA |RFC 7836|
+------------------+--------------------------------------+--------+
|gostr34102012_512b| id-tc26-gost-3410-12-512-paramSetB |RFC 7836|
+------------------+--------------------------------------+--------+
|gostr34102012_512c| id-tc26-gost-3410-2012-512-paramSetC |RFC 7836|
+------------------+--------------------------------------+--------+
Table 4
This document defines the SIGN function which is used for computing signature value in CertificateVerify message (see Section 6.3.3) as follows.
+-----------------------------------------------------+
| SIGN(M, d_sign) |
|-----------------------------------------------------|
| Input: |
| - the byte string M in B*; |
| - the sign key d_sign: 0 <= d_sign <= q. |
| Output: |
| - signature value sgn in B_{2*l}. |
|-----------------------------------------------------|
| 1. (r, s) = SIGNGOST(M, d_sign) |
| 2. Return str_l(r) | str_l(s) |
|-----------------------------------------------------+
where
The signature value sgn is the concatenation of two strings that are byte representations of r and s values in the little-endian format.
According to [RFC7091] the GOST R 34.10-2012 signature algorithm with 32-byte (256-bit) or 64-byte (512-bit) key length use the GOST R 34.11-2012 [RFC6986] hash algorithm with 32-byte (256-bit) or 64-byte (512-bit) hash code respectively (the hash algorithm is intrinsic to the signature algorithm).
Key exchange and authentication process in case of using GOST cipher suites is defined in [RFC8446] and Section 6.1, Section 6.2. Additionally the proposed cipher suites specify some Handshake messages (see Section 6.3).
TLS 1.3 supports three basic key exchange modes in accordance with [RFC8446]:
All of the cipher suites described in this document use Diffie-Hellman over elliptic curves in (EC)DHE and PSK with (EC)DHE key exchange modes. Diffie-Hellman over finite fields SHOULD NOT be used. This document defines the process of ECDHE shared secret calculation (see Section 6.1.1) and specifies the elliptic curves that can be used during this process (see Section 6.1.2).
In accordance with [RFC8446] PSKs can be divided into two types:
This document defines that PSK-only key exchange mode SHOULD be used only with the internal PSKs. External PSKs SHOULD be used together with certificates in PSK with (EC)DHE mode only.
ECDHE parameters for both clients and servers are encoded in the opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
For GOST cipher suites the contents are the serialized value of the following struct:
struct {
opaque X[coordinate_length];
opaque Y[coordinate_length];
} PlainPointRepresentation;
X and Y, respectively, contain the binary representations of the x and y values of point Q (Q = (x, y)) in the little-endian format and are specified as follows:
The coordinate_length value is defined in Table 5.
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
2. Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ..., (d_C^{i_r}, Q_C^{i_r}) corresponding to E_{i_1}, ..., E_{i_r} curves, where for each i in {i_1, ..., i_r}:
3. Sends ClientHello message specified in accordance with Section 4.1.2 of [RFC8446] and Section 6.3.1, which contains:
4. In case of receiving HelloRetryRequest message client should return to step 1 and correct parameters according to Section 4.1.2 of [RFC8446]. 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_res belongs to E_res. If this check fails, the client MUST abort the handshake with "handshake_failure" alert.
6. Generates Q^ECDHE:
7. Client MUST check whether the computed shared secret Q^ECDHE is not equal to zero point. 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 little-endian format:
where coordinate_length is defined in Table 5.
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 curves E_1, ..., E_R indicated in supported_group 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 MAY send HelloRetryRequest message with key_share extension indicated E_res and wait for the next ClientHello message.
2. Checks whether Q_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:
4. Sends ServerHello message specified in accordance with Section 4.1.3 of [RFC8446] and Section 6.3.1 with key_share extension indicated public ephemeral key value Q_S^res corresponding to E_res.
5. Generates Q^ECDHE:
6. Server MUST check whether the computed shared secret Q^ECDHE is not equal to zero point. 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 little-endian format:
where coordinate_length is defined in Table 5.
The supported_groups extension indicates the set of elliptic curves supported by the client and is defined in [RFC8446].
This document defines the following values for the "Supported Groups" registry:
enum {
GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25),
GC512A(0x26), GC512B(0x27), GC512C(0x28)
} NamedGroup;
Where the values correspond to the following curves and the following values of coordinate_length parameter ("cl" column).
+-----------+--------------------------------------+----+---------+
|Description| Curve Identifier Value | cl |Reference|
+-----------+--------------------------------------+----+---------+
| GC256A | id-tc26-gost-3410-2012-256-paramSetA | 32 | RFC 7836|
+-----------+--------------------------------------+----+---------+
| GC256B |id-GostR3410-2001-CryptoPro-A-ParamSet| 32 | RFC 4357|
+-----------+--------------------------------------+----+---------+
| GC256C |id-GostR3410-2001-CryptoPro-B-ParamSet| 32 | RFC 4357|
+-----------+--------------------------------------+----+---------+
| GC256D |id-GostR3410-2001-CryptoPro-C-ParamSet| 32 | RFC 4357|
+-----------+--------------------------------------+----+---------+
| GC512A | id-tc26-gost-3410-12-512-paramSetA | 64 | RFC 7836|
+-----------+--------------------------------------+----+---------+
| GC512B | id-tc26-gost-3410-12-512-paramSetB | 64 | RFC 7836|
+-----------+--------------------------------------+----+---------+
| GC512C | id-tc26-gost-3410-2012-512-paramSetC | 64 | RFC 7836|
+-----------+--------------------------------------+----+---------+
Table 5
These values are the same as in [DraftGostTLS12].
In accordance with [RFC8446] authentication can happen via signature with certificate or via symmetric pre-shared key (PSK). The server side of the channel is always authenticated; the client side is optionally authenticated.
PSK-based authentication happens as a side effect of key exchange. This document defines that external PSKs SHOULD be combined only with the mutual autentication.
Certificate-based authentication happens via authentication messages. This document defines the signature schemes that are used for certificate-based authentication (see Section 5) and specifies some autehtication messages (see Section 6.3.2, Section 6.3.3).
The proposed cipher suites specify the ClientHello, ServerHello, CertificateRequest and CertificateVerify handshake messages, that are described in further detail below.
The ClientHello message is generated in accordance with the following requirements.
The ServerHello message is generated in accordance with the following requirements.
This message is sent when requesting client authentication and is specified in accordance with [RFC8446] as follows.
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>;
} CertificateRequest;
If the GOST cipher suite is negotiated, the CertificateRequest message MUST meet the following requirements.
This CertificateVerify message is used to provide explicit proof that an endpoint possesses the private key corresponding to its certificate and is specified in accordance with [RFC8446] as follows.
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
If the GOST cipher suite is negotiated, the CertificateVerify message MUST meet the following requirements.
IANA is asked to assign numbers TBD1, TBD2, TBD3 and TBD4 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.
+-----+-----------------------------------------+-------+----------+
|Value| Description |DTLS-OK| Reference|
+-----+-----------------------------------------+-------+----------+
|TBD1 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L| ? | this RFC |
+-----+-----------------------------------------+-------+----------+
|TBD2 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L | ? | this RFC |
+-----+-----------------------------------------+-------+----------+
|TBD3 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S| ? | this RFC |
+-----+-----------------------------------------+-------+----------+
|TBD4 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | ? | this RFC |
+-----+-----------------------------------------+-------+----------+
Table 6
IANA is asked to assign numbers TBD5, TBD6, TBD7, TBD8, TBD9, TBD10 and TBD11 with the names gostr34102012_256a, gostr34102012_256b, gostr34102012_256c, gostr34102012_256d, gostr34102012_512a, gostr34102012_512b, gostr34102012_512c to the "TLS SignatureAlgorithm" registry, as shown below.
+-----------+----------------------+---------+----------+
| Value | Description | DTLS-OK | Reference|
+-----------+----------------------+---------+----------+
| TBD5 | gostr34102012_256a | ? | this RFC |
+-----------+----------------------+---------+----------+
| TBD6 | gostr34102012_256b | ? | this RFC |
+-----------+----------------------+---------+----------+
| TBD7 | gostr34102012_256c | ? | this RFC |
+-----------+----------------------+---------+----------+
| TBD8 | gostr34102012_256d | ? | this RFC |
+-----------+----------------------+---------+----------+
| TBD9 | gostr34102012_512a | ? | this RFC |
+-----------+----------------------+---------+----------+
| TBD10 | gostr34102012_512b | ? | this RFC |
+-----------+----------------------+---------+----------+
| TBD11 | gostr34102012_512c | ? | this RFC |
+-----------+----------------------+---------+----------+
Table 7
Due to historical reasons in addition to the curve identifier values listed in Table 5 there exist some extra identifier values that correspond to the signature schemes as follows.
+--------------------+-------------------------------------------+
| Description | Curve Identifier Value |
+--------------------+-------------------------------------------+
| gostr34102012_256b | id-GostR3410_2001-CryptoPro-XchA-ParamSet |
| | id-tc26-gost-3410-2012-256-paramSetB |
+--------------------+-------------------------------------------+
| gostr34102012_256c | id-tc26-gost-3410-2012-256-paramSetC |
+--------------------+-------------------------------------------+
| gostr34102012_256d | id-GostR3410-2001-CryptoPro-XchB-ParamSet |
| | id-tc26-gost-3410-2012-256-paramSetD |
+--------------------+-------------------------------------------+
Table 8
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.
In order to create an effective implementation and to resist attacks client and server SHOULD stick to the following rules.
1. While using TLSTREE algorithm function KDF_j, j = 1, 2, 3, SHOULD be invoked only if sequence number seqnum reaches such value that
Otherwise the previous value should be used.
2. For each pre-shared 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.
3. Server SHOULD NOT send Application Data prior to receiving first client's Finished message in a mutually authenticated connection.
| [GOST3410-2012] | Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature", GOST R 34.10-2012, 2012. |
| [GOST3411-2012] | Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic Data Security. Hashing function", GOST R 34.11-2012, 2012. |
| [GOST3412-2015] | Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Block ciphers", GOST R 34.12-2015, 2015. |
TODO