RFC 9367: GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
- S. Smyshlyaev, Ed.,
- E. Alekseev,
- E. Griboedova,
- A. Babueva,
- L. Nikiforova
Abstract
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 document defines the cipher suites, signature schemes,
and key exchange mechanisms for using Russian cryptographic
standards, called GOST algorithms, with TLS Version 1.3. Additionally, this document
specifies a profile of TLS 1.3 with GOST algorithms to
facilitate interoperable implementations
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2023 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://
1. 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.12-2015 [RFC7801], GOST R 34.11-2012 [RFC6986], and GOST R 34.10-2012 [RFC7091].¶
The TLS13_GOST cipher suites (see Section 4) have the following values:¶
Each TLS13_GOST cipher suite specifies a pair (record protection algorithm, hash algorithm) such that:¶
Note: The TLS13_GOST cipher suites are divided into two types: the "_S" (strong) cipher suites and the "_L" (light) cipher suites (depending on the key lifetime limitations, see Sections 4.1.2 and 4.1.3).¶
The TLS13_GOST signature schemes have the following values:¶
Each TLS13_GOST signature scheme specifies a pair (signature algorithm, elliptic curve) such that:¶
This document also specifies the key exchange mechanism with GOST algorithms for the TLS 1.3 protocol (see Section 6.1).¶
Additionally, this document specifies a TLS13_GOST profile of the TLS 1.3 protocol with GOST algorithms so that implementers can produce interoperable implementations
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
3. Basic Terms and Definitions
This document follows the terminology from [RFC8446BIS] for "main secret".¶
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 in 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_{j-i+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 transformation that maps an integer i = 256t-1 * i_1 + ... + 256 * i_{t-1} + i_t into the byte string STR_t(i) = (i_1, ... , i_t) in B_t (the interpretation of the integer as a byte string in big-endian format).¶
- str_t
- The transformation that maps an integer i = 256t-1 * i_t + ... + 256 * i_2 + i_1 into the byte string str_t(i) = (i_1, ... , i_t) in B_t (the interpretation of the integer as a byte string in little-endian 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 the client in "supported
_groups" extension.¶ - O_i
- The zero point of the elliptic curve E_i.¶
- m_i
- The order of the group of points belonging to the elliptic curve E_i.¶
- q_i
- The order of the cyclic subgroup of the group of points belonging to the elliptic curve E_i.¶
- h_i
- The cofactor of the cyclic subgroup that is equal to m_i / q_i.¶
- Q_sign
- The public key stored in the 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 that 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 that consists of the private key and the public key corresponding to the elliptic curve E_i.¶
4. Cipher Suite Definition
This section defines the following four TLS13_GOST cipher suites:¶
Each cipher suite specifies a pair consisting of a record protection algorithm (see Section 4.1) and a hash algorithm (Section 4.2).¶
4.1. Record Protection Algorithm
In accordance with Section 5.2 of [RFC8446], the record protection algorithm translates a TLSPlaintext structure into a TLSCiphertext structure.
If the TLS13_GOST cipher suite is negotiated, the encrypted
AEADEncrypted =
AEAD
where¶
Note 1: The AEAD-Encrypt function is exactly the same as the AEAD-Encrypt function defined in [RFC8446], such that the key
(the first argument) is calculated from sender
Note 2: Sequence number is a value in the range 0-SNMAX,
where the SNMAX value is defined in Section 4.1.3. The SNMAX parameter is specified by a
particular TLS13_GOST cipher suite to limit an amount of
data that can be encrypted under the same traffic key
material
The record deprotection algorithm reverses the process of the record protection.
In order to decrypt and verify a protected record with sequence
number seqnum, the algorithm takes sender
res = AEAD
where the AEAD-Decrypt function is as defined in Section 4.1.1.¶
Note: The AEAD-Decrypt function is exactly the same as the AEAD-Decrypt function defined in [RFC8446], such that the key
(the first argument) is calculated from sender
4.1.1. AEAD Algorithm
The AEAD-Encrypt and AEAD-Decrypt functions are defined as follows:¶
where¶
Cipher suites TLS
Cipher suites TLS
4.1.2. TLSTREE
The TLS13_GOST cipher suites use the TLSTREE function to support the external re-keying approach (see [RFC8645]). The TLSTREE function is defined as follows:¶
TLSTREE(K_root, i) = KDF
where¶
4.1.3. SNMAX Parameter
The SNMAX parameter is the maximum number of records encrypted under the same traffic key material
4.2. Hash Algorithm
The Hash algorithm is used for the key derivation process (see Section 7.1 of [RFC8446]), Finished message calculation (see Section 4.4.4 of [RFC8446]), Transcript-Hash function computation (see Section 4.4.1 of [RFC8446]), Pre-Shared Key (PSK) binder value calculation (see Section 4.2.11.2 of [RFC8446]), external re-keying approach (see Section 4.1.2), and other purposes.¶
If a TLS13_GOST cipher suite is negotiated, the Hash algorithm MUST be the GOST R 34.11-2012 hash algorithm [RFC6986] with a 32-byte (256-bit) hash value.¶
5. Signature Scheme Definition
This section defines the following seven TLS13_GOST signature schemes:¶
One of the TLS13_GOST signature schemes listed above SHOULD be used with the TLS13_GOST profile.¶
Each signature scheme specifies a pair consisting of the signature algorithm (see Section 5.1) and the elliptic curve (see Section 5.2). The procedure to calculate the signature value using TLS13_GOST signature schemes is defined in Section 5.3.¶
5.1. Signature Algorithm
Signature algorithms corresponding to the TLS13_GOST signature schemes are defined as follows:¶
5.2. Elliptic Curve
Elliptic curves corresponding to the TLS13_GOST signature schemes are defined as follows:¶
5.3. SIGN Function
If the TLS13_GOST signature scheme is used, the signature value in the Certificate
where¶
Note: The signature value sgn is the concatenation of two strings that are byte representations of r and s values in the little-endian format.¶
6. Key Exchange and Authentication
The key exchange and authentication process for using the TLS13_GOST profile is defined in Sections 6.1, 6.2, and 6.3.¶
6.1. Key Exchange
The TLS13_GOST profile supports three basic key exchange modes that are defined in [RFC8446]: Ephemeral Elliptic Curve Diffie-Hellman (ECDHE), PSK-only, and PSK with ECDHE.¶
Note: In accordance with [RFC8446], TLS 1.3 also supports key exchange modes based on the Diffie-Hellman protocol over finite fields. However, the TLS13_GOST profile MUST use modes based on the Diffie-Hellman protocol over elliptic curves.¶
In accordance with [RFC8446], PSKs can be divided into two types:¶
If the TLS13_GOST profile is used, PSK-only key exchange mode SHOULD be established via the internal PSKs, and external PSKs SHOULD be used only in PSK with ECDHE mode (see more in Section 9).¶
If the TLS13_GOST profile is used and ECDHE or PSK with ECDHE key exchange mode is used, the ECDHE shared secret SHOULD be calculated in accordance with Section 6.1.1 on the basis of one of the elliptic curves defined in Section 6.1.2.¶
6.1.1. ECDHE Shared Secret Calculation
If the TLS13_GOST profile is used, the ECDHE shared secret SHOULD be calculated in accordance with Sections 6.1.1.1 and 6.1.1.2. The public ephemeral keys used to obtain the ECDHE shared secret SHOULD be represented in the format described in Section 6.1.1.3.¶
6.1.1.1. ECDHE Shared Secret Calculation on the Client Side
The client calculates the ECDHE shared secret in accordance with the following steps:¶
- Step 1.
-
The client 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¶
- Step 2.
-
The client 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}:¶
- Step 3.
-
The client sends the ClientHello message specified in accordance with Section 4.1.2 of [RFC8446] and Section 6.3.1 that contains:¶
Note: The client MAY send an empty "key_share" extension in the first ClientHello message to request a group selection from the server in the Hello
Retry Request message and to generate an ephemeral key for the selected group only. The ECDHE shared secret may be calculated without sending Hello Retry Request message if the "key_share" extension in the first ClientHello message contains the value corresponding to the curve that is selected by the server.¶ - Step 4.
-
If the Hello
Retry Request message is received, the client MUST return to Step 1 and choose correct parameters in accordance with Section 4.1.2 of [RFC8446]. If the ServerHello message is received, the client proceeds to the next step. In other cases, the client MUST terminate the connection with the "unexpected _message" alert.¶ - Step 5.
-
The client extracts curve E_res and ephemeral key Q_S^res, res in {1, ..., R}, from the ServerHello message and checks whether Q_S^res belongs to E_res. If this check fails, the client MUST terminate the connection with "handshake
_failure" alert.¶ - Step 6.
-
The client generates Q^ECDHE:¶
- Step 7.
-
The client MUST check whether the calculated shared secret Q^ECDHE is not equal to the zero point O_res. If this check fails, the client MUST terminate the connection with "handshake
_failure" alert.¶ - Step 8.
-
The ECDHE shared secret is the byte representation of the coordinate X^ECDHE of the point Q^ECDHE in the little-endian format:¶
ECDHE = str
_{coordinate _length} (X^ECDHE ),¶ where the coordinate
_length value is defined by the particular elliptic curve (see Section 6.1.2).¶
6.1.1.2. ECDHE Shared Secret Calculation on Server Side
Upon receiving the ClientHello message, the server calculates the ECDHE shared secret in accordance with the following steps:¶
- Step 1.
-
The server chooses the curve E_res, res in {1, ..., R}, from the list of the curves E_1, ..., E_R indicated in the "supported
_groups" extension in the ClientHello message and the corresponding public ephemeral key Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r}, 1 <= i_1 <= i_r <= R, indicated in the "key_share" extension. If the corresponding public ephemeral key is not found (res in {1, ..., R}\{i_1, ..., i_r}), the server MUST send the Hello Retry Request message with the "key_share" extension indicating the selected elliptic curve E_res and wait for the new ClientHello message.¶ - Step 2.
-
The server checks whether Q_C^res belongs to E_res. If this check fails, the server MUST terminate the connection with "handshake
_failure" alert.¶ - Step 3.
-
The server generates ephemeral key pair (d_S^res, Q_S^res) corresponding to E_res:¶
- Step 4.
-
The server sends the ServerHello message generated in accordance with Section 4.1.3 of [RFC8446] and Section 6.3.1 with the "key_share" extension that contains public ephemeral key Q_S^res corresponding to E_res.¶
- Step 5.
-
The server generates Q^ECDHE:¶
Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res.¶
- Step 6.
-
The server MUST check whether the calculated 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.¶ - Step 7.
-
The ECDHE shared secret is the byte representation of the coordinate X^ECDHE of the point Q^ECDHE in the little-endian format:¶
ECDHE = str
_{coordinate _length} (X^ECDHE ),¶ where the coordinate
_length value is defined by the particular elliptic curve (see Section 6.1.2).¶
6.1.1.3. Public Ephemeral Key Representation
This section defines the representation format of the public ephemeral keys generated during the ECDHE shared secret calculation (see Sections 6.1.1.1 and 6.1.1.2).¶
If the TLS13_GOST profile is used and ECDHE or PSK with ECDHE key exchange mode is used, the public ephemeral key Q
indicated in the Key
where X and Y, respectively, contain the byte representations of x and y values of the point Q (Q = (x, y)) in the little-endian format and are specified as follows:¶
The coordinate
6.1.2. Values for the TLS Supported Groups Registry
The "supported
This section defines the following seven elliptic curves:¶
If the TLS13_GOST profile is used and ECDHE or PSK with ECDHE key exchange mode is used, one of the elliptic curves listed above SHOULD be used.¶
Each curve corresponds to the particular identifier and specifies the value of coordinate
Note: The identifier values and the corresponding elliptic curves are the same as in [RFC9189].¶
6.2. Authentication
In accordance with [RFC8446], authentication can be performed via a signature with a certificate or via a symmetric PSK. The server side is always authenticated; the client side is optionally authenticated.¶
PSK-based authentication is performed as a side effect of key exchange. If the TLS13_GOST profile is used, external PSKs SHOULD be combined only with mutual authentication (see Section 9).¶
Certificate
6.3. Handshake Messages
The TLS13_GOST profile specifies the ClientHello, ServerHello, Certificate
6.3.1. Hello Messages
The ClientHello message is sent when the client first connects to the server or responds
to the Hello
If the TLS13_GOST profile is used, the ClientHello message MUST meet the following requirements:¶
The ServerHello message is sent by the server in response to the ClientHello message to negotiate an acceptable set of handshake parameters based on the ClientHello message and is specified in accordance with Section 4.1.3 of [RFC8446].¶
If the TLS13_GOST profile is used, the ServerHello message MUST meet the following requirements:¶
6.3.2. CertificateRequest
This message is sent when the server requests client authentication via a certificate and is specified in accordance with Section 4.3.2 of [RFC8446].¶
If the TLS13_GOST profile is used, the Certificate
6.3.3. 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 [RFC8446].¶
If the TLS13_GOST profile is used, the Certificate message MUST meet the following requirements.¶
6.3.4. CertificateVerify
This message is sent to provide explicit proof that the endpoint has the private key corresponding to the public key indicated in its certificate and is specified in accordance with Section 4.4.3 of [RFC8446].¶
If the TLS13_GOST profile is used, the
Certificate
7. IANA Considerations
IANA has added the following values to the "TLS Cipher Suites" registry with a reference to this RFC:¶
IANA has added the following values to the "TLS Signature
8. Historical Considerations
In addition to the curve identifier values listed in Table 5, there are some additional identifier values that correspond to the signature schemes for historical reasons. They are as follows:¶
The client should be prepared to handle any of them correctly if the corresponding signature scheme is included in the "signature
9. Security Considerations
In order to create an efficient and side-channel resistant implementation while using the TLSTREE algorithm, the functions KDF_j, j = 1, 2, 3, SHOULD be called only when necessary (when the record sequence number seqnum reaches such a value that seqnum & C_j != (seqnum - 1) & C_j). Otherwise, the previous value should be used.¶
10. References
10.1. Normative References
- [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC6986]
-
Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, DOI 10
.17487 , , <https:///RFC6986 www >..rfc -editor .org /info /rfc6986 - [RFC7091]
-
Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: Digital Signature Algorithm", RFC 7091, DOI 10
.17487 , , <https:///RFC7091 www >..rfc -editor .org /info /rfc7091 - [RFC7801]
-
Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher "Kuznyechik"", RFC 7801, DOI 10
.17487 , , <https:///RFC7801 www >..rfc -editor .org /info /rfc7801 - [RFC7836]
-
Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012", RFC 7836, DOI 10
.17487 , , <https:///RFC7836 www >..rfc -editor .org /info /rfc7836 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446 - [RFC8645]
-
Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric Keys", RFC 8645, DOI 10
.17487 , , <https:///RFC8645 www >..rfc -editor .org /info /rfc8645 - [RFC8891]
-
Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015: Block Cipher "Magma"", RFC 8891, DOI 10
.17487 , , <https:///RFC8891 www >..rfc -editor .org /info /rfc8891 - [RFC9058]
-
Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E. Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058, DOI 10
.17487 , , <https:///RFC9058 www >..rfc -editor .org /info /rfc9058 - [RFC9189]
-
Smyshlyaev, S., Ed., Belyavsky, D., and E. Alekseev, "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2", RFC 9189, DOI 10
.17487 , , <https:///RFC9189 www >..rfc -editor .org /info /rfc9189
10.2. Informative References
- [RFC8446BIS]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft
-ietf , , <https://-tls -rfc8446bis -05 datatracker >..ietf .org /doc /html /draft -ietf -tls -rfc8446bis -05
Appendix A. Test Examples
A.1. Example 1
A.1.1. Test Case
Test examples are given for the following instance of the TLS13_GOST profile:¶
A.1.2. Test Examples
A.2. Example 2
A.2.1. Test Case
Test examples are given for the following instance of the TLS13_GOST profile:¶