rfc9367.original   rfc9367.txt 
Network Working Group S.V. Smyshlyaev, Ed. Independent Submission S. Smyshlyaev, Ed.
Internet-Draft E.K. Alekseev Request for Comments: 9367 E. Alekseev
Intended status: Informational E.S. Griboedova Category: Informational E. Griboedova
Expires: 15 March 2023 A.A. Babueva ISSN: 2070-1721 A. Babueva
L.O. Nikiforova L. Nikiforova
CryptoPro CryptoPro
11 September 2022 February 2023
GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version GOST Cipher Suites for Transport Layer Security (TLS) Protocol
1.3 Version 1.3
draft-smyshlyaev-tls13-gost-suites-08
Abstract Abstract
The purpose of this document is to make the Russian cryptographic The purpose of this document is to make the Russian cryptographic
standards available to the Internet community for their standards available to the Internet community for their
implementation in the Transport Layer Security (TLS) Protocol Version implementation in the Transport Layer Security (TLS) Protocol Version
1.3. 1.3.
This document defines the cipher suites, signature schemes, and key This document defines the cipher suites, signature schemes, and key
exchange mechanisms for using Russian cryptographic standards, called exchange mechanisms for using Russian cryptographic standards, called
GOST algorithms, with Transport Layer Security (TLS) Version 1.3. GOST algorithms, with TLS Version 1.3. Additionally, this document
Additionally, this document specifies a profile of TLS 1.3 with GOST specifies a profile of TLS 1.3 with GOST algorithms to facilitate
algorithms to facilitate interoperable implementations. The IETF has interoperable implementations. The IETF has not endorsed the cipher
not endorsed the cipher suites, signature schemes, key exchange suites, signature schemes, or key exchange mechanisms described in
mechanism described in this document. this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 15 March 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9367.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document
3. Basic Terms and Definitions . . . . . . . . . . . . . . . . . 4 3. Basic Terms and Definitions
4. Cipher Suite Definition . . . . . . . . . . . . . . . . . . . 6 4. Cipher Suite Definition
4.1. Record Protection Algorithm . . . . . . . . . . . . . . . 6 4.1. Record Protection Algorithm
4.1.1. AEAD Algorithm . . . . . . . . . . . . . . . . . . . 8 4.1.1. AEAD Algorithm
4.1.2. TLSTREE . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.2. TLSTREE
4.1.3. SNMAX parameter . . . . . . . . . . . . . . . . . . . 10 4.1.3. SNMAX Parameter
4.2. Hash Algorithm . . . . . . . . . . . . . . . . . . . . . 11 4.2. Hash Algorithm
5. Signature Scheme Definition . . . . . . . . . . . . . . . . . 11 5. Signature Scheme Definition
5.1. Signature Algorithm . . . . . . . . . . . . . . . . . . . 11 5.1. Signature Algorithm
5.2. Elliptic Curve . . . . . . . . . . . . . . . . . . . . . 12 5.2. Elliptic Curve
5.3. SIGN function . . . . . . . . . . . . . . . . . . . . . . 13 5.3. SIGN Function
6. Key Exchange and Authentication . . . . . . . . . . . . . . . 13 6. Key Exchange and Authentication
6.1. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Key Exchange
6.1.1. ECDHE Shared Secret Calculation . . . . . . . . . . . 14 6.1.1. ECDHE Shared Secret Calculation
6.1.1.1. ECDHE Shared Secret Calculation on Client Side . 14 6.1.1.1. ECDHE Shared Secret Calculation on the Client Side
6.1.1.2. ECDHE Shared Secret Calculation on Server Side . 16 6.1.1.2. ECDHE Shared Secret Calculation on Server Side
6.1.1.3. Public ephemeral key representation . . . . . . . 17 6.1.1.3. Public Ephemeral Key Representation
6.1.2. Values for the TLS Supported Groups Registry . . . . 17 6.1.2. Values for the TLS Supported Groups Registry
6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 18 6.2. Authentication
6.3. Handshake Messages . . . . . . . . . . . . . . . . . . . 19 6.3. Handshake Messages
6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 19 6.3.1. Hello Messages
6.3.2. CertificateRequest . . . . . . . . . . . . . . . . . 20 6.3.2. CertificateRequest
6.3.3. Certificate . . . . . . . . . . . . . . . . . . . . . 20 6.3.3. Certificate
6.3.4. CertificateVerify . . . . . . . . . . . . . . . . . . 21 6.3.4. CertificateVerify
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations
8. Historical considerations . . . . . . . . . . . . . . . . . . 22 8. Historical Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References
Appendix A. Test Examples
Appendix A. Test Examples . . . . . . . . . . . . . . . . . . . 24 A.1. Example 1
A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 24 A.1.1. Test Case
A.1.1. Test case . . . . . . . . . . . . . . . . . . . . . . 25 A.1.2. Test Examples
A.1.2. Test examples . . . . . . . . . . . . . . . . . . . . 25 A.2. Example 2
A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 59 A.2.1. Test Case
A.2.1. Test case . . . . . . . . . . . . . . . . . . . . . . 59 A.2.2. Test Examples
A.2.2. Test examples . . . . . . . . . . . . . . . . . . . . 59 Contributors
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 84 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84
1. Introduction 1. Introduction
This document defines four new cipher suites (the TLS13_GOST cipher This document defines four new cipher suites (the TLS13_GOST cipher
suites) and seven new signature schemes (the TLS13_GOST signature suites) and seven new signature schemes (the TLS13_GOST signature
schemes) for the Transport Layer Security (TLS) Protocol Version 1.3, schemes) for the Transport Layer Security (TLS) Protocol Version 1.3
that are based on Russian cryptographic standards GOST R 34.12-2015 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 [RFC7801], GOST R 34.11-2012 [RFC6986], and GOST R 34.10-2012
[RFC7091]. [RFC7091].
The TLS13_GOST cipher suites (see Section 4) have the following The TLS13_GOST cipher suites (see Section 4) have the following
values: values:
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}; 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_L = {0xC1, 0x04}
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}.
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 Each TLS13_GOST cipher suite specifies a pair (record protection
algorithm, hash algorithm) such that: algorithm, hash algorithm) such that:
* The record protection algorithm is the AEAD algorithm (see * The record protection algorithm is the Authenticated Encryption
Section 4.1.1) based on the GOST R 34.12-2015 block cipher with Associated Data (AEAD) algorithm (see Section 4.1.1) based on
[RFC7801] in the Multilinear Galois Mode (MGM) [RFC9058] and the the GOST R 34.12-2015 block cipher [RFC7801] in the Multilinear
external re-keying approach (see [RFC8645]) intended for Galois Mode (MGM) [RFC9058] and the external re-keying approach
increasing the lifetime of symmetric keys used to protect records. (see [RFC8645]) intended for increasing the lifetime of symmetric
keys used to protect records.
* The hash algorithm is the GOST R 34.11-2012 algorithm [RFC6986]. * The hash algorithm is the GOST R 34.11-2012 algorithm [RFC6986].
Note: The TLS13_GOST cipher suites are divided into two types Note: The TLS13_GOST cipher suites are divided into two types: the
(depending on the key lifetime limitations, see Section 4.1.2 and "_S" (strong) cipher suites and the "_L" (light) cipher suites
Section 4.1.3): the "_S" (strong) cipher suites and the "_L" (light) (depending on the key lifetime limitations, see Sections 4.1.2 and
cipher suites. 4.1.3).
The TLS13_GOST signature schemes have the following values: The TLS13_GOST signature schemes have the following values:
gostr34102012_256a = 0x0709; gostr34102012_256a = 0x0709
gostr34102012_256b = 0x070A; gostr34102012_256b = 0x070A
gostr34102012_256c = 0x070B;
gostr34102012_256d = 0x070C; gostr34102012_256c = 0x070B
gostr34102012_512a = 0x070D; gostr34102012_256d = 0x070C
gostr34102012_512b = 0x070E; gostr34102012_512a = 0x070D
gostr34102012_512c = 0x070F. gostr34102012_512b = 0x070E
gostr34102012_512c = 0x070F
Each TLS13_GOST signature scheme specifies a pair (signature Each TLS13_GOST signature scheme specifies a pair (signature
algorithm, elliptic curve) such that: algorithm, elliptic curve) such that:
* The signature algorithm is the GOST R 34.10-2012 algorithm * The signature algorithm is the GOST R 34.10-2012 algorithm
[RFC7091]. [RFC7091].
* The elliptic curve is one of the curves defined in Section 5.2. * The elliptic curve is one of the curves defined in Section 5.2.
Also, this document specifies the key exchange mechanism with GOST This document also specifies the key exchange mechanism with GOST
algorithms for TLS 1.3 protocol (see Section 6.1). algorithms for the TLS 1.3 protocol (see Section 6.1).
Additionally, this document specifies a TLS13_GOST profile of the TLS Additionally, this document specifies a TLS13_GOST profile of the TLS
1.3 protocol with GOST algorithms so that implementers can produce 1.3 protocol with GOST algorithms so that implementers can produce
interoperable implementations. It uses TLS13_GOST cipher suites, interoperable implementations. It uses TLS13_GOST cipher suites,
TLS13_GOST signature schemes, key exchange mechanism that defined in TLS13_GOST signature schemes, and key exchange mechanisms that are
this document. defined in this document.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Basic Terms and Definitions 3. Basic Terms and Definitions
This document follows the terminology from [I-D.ietf-tls-rfc8446bis] This document follows the terminology from [RFC8446BIS] for "main
for "main secret". secret".
This document uses the following terms and definitions for the sets This document uses the following terms and definitions for the sets
and operations on the elements of these sets: and operations on the elements of these sets:
B_t the set of byte strings of length t, t >= 0, for t = 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 0, the B_t set consists of a single empty string of
zero length. If A is an element in B_t, then A = 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 (a_1, a_2, ... , a_t), where a_1, a_2, ... , a_t are
in {0, ... , 255}; in {0, ... , 255}.
B* the set of all byte strings of a finite length B* The set of all byte strings of a finite length
(hereinafter referred to as strings), including the (hereinafter referred to as strings) including the
empty string; empty string.
A[i..j] the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in 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 B_{j-i+1}, where A = (a_1, a_2, ... , a_t) in B_t and
1<=i<=j<=t; 1<=i<=j<=t.
A[i] the integer a_i in {0, ... , 255}, where A = (a_1, 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_2, ... , a_t) in B_t and 1<=i<=t.
|A| the length of the byte string A in bytes; |A| The length of the byte string A in bytes.
A | C the concatenation of strings A and C both belonging A | C The concatenation of strings A and C both belonging
to B*, i.e., a string in B_{|A|+|C|}, where the left 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_|A| is equal to A and the right
substring in B_|C| is equal to C; substring in B_|C| is equal to C.
i & j bitwise AND of integers i and j; i & j Bitwise AND of integers i and j.
STR_t the transformation that maps an integer i = 256^(t-1) STR_t The transformation that maps an integer i = 256^(t-1)
* i_1 + ... + 256 * i_{t-1} + i_t into the byte * i_1 + ... + 256 * i_{t-1} + i_t into the byte
string STR_t(i) = (i_1, ... , i_t) in B_t (the string STR_t(i) = (i_1, ... , i_t) in B_t (the
interpretation of the integer as a byte string in interpretation of the integer as a byte string in
big-endian format); big-endian format).
str_t the transformation that maps an integer i = 256^(t-1) str_t The transformation that maps an integer i = 256^(t-1)
* i_t + ... + 256 * i_2 + i_1 into the byte string * i_t + ... + 256 * i_2 + i_1 into the byte string
str_t(i) = (i_1, ... , i_t) in B_t (the str_t(i) = (i_1, ... , i_t) in B_t (the
interpretation of the integer as a byte string in interpretation of the integer as a byte string in
little-endian format); little-endian format).
k the length of the block cipher key in bytes; k The length of the block cipher key in bytes.
n the length of the block cipher block in bytes; n The length of the block cipher block in bytes.
IVlen the length of the initialization vector in bytes; IVlen The length of the initialization vector in bytes.
S the length of the authentication tag in bytes; S The length of the authentication tag in bytes.
E_i the elliptic curve indicated by the client in E_i The elliptic curve indicated by the client in
"supported_groups" extension; "supported_groups" extension.
O_i the zero point of the elliptic curve E_i; O_i The zero point of the elliptic curve E_i.
m_i the order of group of points belonging to the m_i The order of the group of points belonging to the
elliptic curve E_i; elliptic curve E_i.
q_i the order of the cyclic subgroup of the group of q_i The order of the cyclic subgroup of the group of
points belonging to the elliptic curve E_i; points belonging to the elliptic curve E_i.
h_i the cofactor of the cyclic subgroup which is equal to h_i The cofactor of the cyclic subgroup that is equal to
m_i / q_i; m_i / q_i.
Q_sign the public key stored in endpoint's certificate; Q_sign The public key stored in the endpoint's certificate.
d_sign the private key that corresponds to the Q_sign key; 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; 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 (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 private key and the public key corresponding to the
elliptic curve E_i; elliptic curve E_i.
(d_S^i, Q_S^i) the server's ephemeral key pair which consists of the (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 private key and the public key corresponding to the
elliptic curve E_i. elliptic curve E_i.
4. Cipher Suite Definition 4. Cipher Suite Definition
This section defines the following four TLS13_GOST cipher suites: This section defines the following four TLS13_GOST cipher suites:
CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}; * CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1,
CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04}; 0x03};
CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05};
CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06};
Each cipher suite specifies a pair of a record protection algorithm * CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04};
(see Section 4.1) and a hash algorithm (Section 4.2).
* CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1,
0x05};
* CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}.
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 4.1. Record Protection Algorithm
In accordance with Section 5.2 of [RFC8446], the record protection In accordance with Section 5.2 of [RFC8446], the record protection
algorithm translates a TLSPlaintext structure into a TLSCiphertext algorithm translates a TLSPlaintext structure into a TLSCiphertext
structure. If the TLS13_GOST cipher suite is negotiated, the structure. If the TLS13_GOST cipher suite is negotiated, the
encrypted_record field of the TLSCiphertext structure MUST be set to encrypted_record field of the TLSCiphertext structure MUST be set to
the AEADEncrypted value computed as follows: the AEADEncrypted value computed as follows:
AEADEncrypted = AEAD-Encrypt(sender_record_write_key, nonce, AEADEncrypted = AEAD-Encrypt(sender_record_write_key, nonce,
skipping to change at page 7, line 4 skipping to change at line 291
structure. If the TLS13_GOST cipher suite is negotiated, the structure. If the TLS13_GOST cipher suite is negotiated, the
encrypted_record field of the TLSCiphertext structure MUST be set to encrypted_record field of the TLSCiphertext structure MUST be set to
the AEADEncrypted value computed as follows: the AEADEncrypted value computed as follows:
AEADEncrypted = AEAD-Encrypt(sender_record_write_key, nonce, AEADEncrypted = AEAD-Encrypt(sender_record_write_key, nonce,
additional_data, plaintext), additional_data, plaintext),
where where
* the AEAD-Encrypt function is defined in Section 4.1.1; * the AEAD-Encrypt function is defined in Section 4.1.1;
* the sender_record_write_key is a key derived from sender_write_key * the sender_record_write_key is a key derived from sender_write_key
(see Section 7.3 of [RFC8446]) using the TLSTREE function defined (see Section 7.3 of [RFC8446]) using the TLSTREE function defined
in Section 4.1.2 and sequence number seqnum as follows: in Section 4.1.2 and sequence number seqnum as follows:
sender_record_write_key = TLSTREE(sender_write_key, seqnum); sender_record_write_key = TLSTREE(sender_write_key, seqnum);
* the nonce is a value derived from sequence number seqnum and * the nonce is a value derived from sequence number seqnum and
sender_write_iv (see Section 7.3 of [RFC8446]) in accordance with sender_write_iv (see Section 7.3 of [RFC8446]) in accordance with
Section 5.3 of [RFC8446]; Section 5.3 of [RFC8446];
* the additional_data value is a record header that is generated in * the additional_data value is a record header that is generated in
accordance with Section 5.2 of [RFC8446]; accordance with Section 5.2 of [RFC8446];
* the plaintext value is the TLSInnerPlaintext structure encoded in * the plaintext value is the TLSInnerPlaintext structure encoded in
accordance with Section 5.2 of [RFC8446]. accordance with Section 5.2 of [RFC8446].
Note1: The AEAD-Encrypt function is exactly the same as the AEAD- Note 1: The AEAD-Encrypt function is exactly the same as the AEAD-
Encrypt function defined in [RFC8446], such that the key (the first Encrypt function defined in [RFC8446], such that the key (the first
argument) is calculated from sender_write_key and sequence number argument) is calculated from sender_write_key and sequence number
seqnum for each message separately to support the external re-keying seqnum for each message separately to support the external re-keying
approach according to [RFC8645]. approach according to [RFC8645].
Note2: Sequence number is a value in the range 0-SNMAX, where the 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 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 specified by a particular TLS13_GOST cipher suite to limit an amount
of data that can be encrypted under the same traffic key material of data that can be encrypted under the same traffic key material
(sender_write_key, sender_write_iv). (sender_write_key, sender_write_iv).
The record deprotection algorithm reverses the process of the record The record deprotection algorithm reverses the process of the record
protection. In order to decrypt and verify a protected record with protection. In order to decrypt and verify a protected record with
sequence number seqnum the algorithm takes as an input: sequence number seqnum, the algorithm takes sender_record_write_key
sender_record_write_key, which is derived from sender_write_key, as an input, which is derived from sender_write_key, nonce,
nonce, additional_data and the AEADEncrypted value. The algorithm additional_data, and the AEADEncrypted value. The algorithm outputs
outputs the res value which is either plaintext or an error the res value that is either plaintext or an error indicating that
indicating that the decryption failed. If a TLS13_GOST cipher suite the decryption failed. If a TLS13_GOST cipher suite is negotiated,
is negotiated, the res value MUST be computed as follows: the res value MUST be computed as follows:
res = AEAD-Decrypt(sender_record_write_key, nonce, res = AEAD-Decrypt(sender_record_write_key, nonce,
additional_data, AEADEncrypted), additional_data, AEADEncrypted),
where the AEAD-Decrypt function is defined in Section 4.1.1. 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- Note: The AEAD-Decrypt function is exactly the same as the AEAD-
Decrypt function defined in [RFC8446], such that the key (the first Decrypt function defined in [RFC8446], such that the key (the first
argument) is calculated from sender_write_key and sequence number argument) is calculated from sender_write_key and sequence number
seqnum for each message separately to support the external re-keying seqnum for each message separately to support the external re-keying
approach according to [RFC8645]. approach according to [RFC8645].
4.1.1. AEAD Algorithm 4.1.1. AEAD Algorithm
The AEAD-Encrypt and AEAD-Decrypt functions are defined as follows. The AEAD-Encrypt and AEAD-Decrypt functions are defined as follows:
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| AEAD-Encrypt(K, nonce, A, P) | | AEAD-Encrypt(K, nonce, A, P) |
|-------------------------------------------------------------------| |-------------------------------------------------------------------|
| Input: | | Input: |
| - encryption key K in B_k, | | - encryption key K in B_k, |
| - unique vector nonce in B_IVlen, | | - unique vector nonce in B_IVlen, |
| - additional authenticated data A in B_r, r >= 0, | | - additional authenticated data A in B_r, r >= 0, |
| - plaintext P in B_t, t >= 0. | | - plaintext P in B_t, t >= 0. |
| Output: | | Output: |
skipping to change at page 8, line 47 skipping to change at line 382
|-------------------------------------------------------------------| |-------------------------------------------------------------------|
| 1. MGMnonce = STR_1(nonce[1] & 0x7f) | nonce[2..IVlen]; | | 1. MGMnonce = STR_1(nonce[1] & 0x7f) | nonce[2..IVlen]; |
| 2. res' = MGM-Decrypt(K, MGMnonce, A, C, T); | | 2. res' = MGM-Decrypt(K, MGMnonce, A, C, T); |
| 3. IF res' = FAIL then return FAIL; | | 3. IF res' = FAIL then return FAIL; |
| 4. IF res' = (A, P) then return P. | | 4. IF res' = (A, P) then return P. |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
where where
* the MGM-Encrypt and MGM-Decrypt functions are defined in * the MGM-Encrypt and MGM-Decrypt functions are defined in
[RFC9058]. The length of authentication tag T is equal to n bytes [RFC9058];
(S = n). The length of the nonce parameter is equal to n bytes
(IVlen = n). * the length of authentication tag T is equal to n bytes (S = n);
* the length of the nonce parameter is equal to n bytes (IVlen = n).
Cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and Cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik
[RFC7801] as a base block cipher for the AEAD algorithm. The block [RFC7801] 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 = length n is 16 bytes (n = 16) and the key length k is 32 bytes (k =
32). 32).
Cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and Cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST use Magma [RFC8891] as a TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST use Magma [RFC8891] as a
base block cipher for the AEAD algorithm. The block length n is 8 base block cipher for the AEAD algorithm. The block length n is 8
skipping to change at page 9, line 34 skipping to change at line 417
where where
* K_root in B_32; * K_root in B_32;
* i in {0, 1, ... , 2^64 - 1}; * i in {0, 1, ... , 2^64 - 1};
* KDF_j(K, D), j = 1, 2, 3, is the key derivation function defined * KDF_j(K, D), j = 1, 2, 3, is the key derivation function defined
as follows: as follows:
KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D), - KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D),
KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D), - KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D),
KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D), - KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D),
where the KDF_GOSTR3411_2012_256 function is defined in [RFC7836], where the KDF_GOSTR3411_2012_256 function is defined in [RFC7836],
K in B_32, D in B_8. K in B_32, D in B_8;
* C_1, C_2, C_3 are the constants defined by each cipher suite as * C_1, C_2, C_3 are the constants defined by each cipher suite as
follows: follows:
+------------------------------------------+----------------------+ +===========================================+======================+
| CipherSuites | C_1, C_2, C_3 | | CipherSuites |C_1, C_2, C_3 |
+------------------------------------------+----------------------+ +===========================================+======================+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L |C_1=0xf800000000000000| | TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L |C_1=0xf800000000000000|
| |C_2=0xfffffff000000000| | | |
| |C_3=0xffffffffffffe000| | |C_2=0xfffffff000000000|
+------------------------------------------+----------------------+ | | |
|TLS_GOSTR341112_256_WITH_MAGMA_MGM_L |C_1=0xffe0000000000000| | |C_3=0xffffffffffffe000|
| |C_2=0xffffffffc0000000| +-------------------------------------------+----------------------+
| |C_3=0xffffffffffffff80| | TLS_GOSTR341112_256_WITH_MAGMA_MGM_L |C_1=0xffe0000000000000|
+------------------------------------------+----------------------+ | | |
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S |C_1=0xffffffffe0000000| | |C_2=0xffffffffc0000000|
| |C_2=0xffffffffffff0000| | | |
| |C_3=0xfffffffffffffff8| | |C_3=0xffffffffffffff80|
+------------------------------------------+----------------------+ +-------------------------------------------+----------------------+
|TLS_GOSTR341112_256_WITH_MAGMA_MGM_S |C_1=0xfffffffffc000000| | TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S |C_1=0xffffffffe0000000|
| |C_2=0xffffffffffffe000| | | |
| |C_3=0xffffffffffffffff| | |C_2=0xffffffffffff0000|
+------------------------------------------+----------------------+ | | |
Table 1 | |C_3=0xfffffffffffffff8|
+-------------------------------------------+----------------------+
| TLS_GOSTR341112_256_WITH_MAGMA_MGM_S |C_1=0xfffffffffc000000|
| | |
| |C_2=0xffffffffffffe000|
| | |
| |C_3=0xffffffffffffffff|
+-------------------------------------------+----------------------+
4.1.3. SNMAX parameter Table 1
4.1.3. SNMAX Parameter
The SNMAX parameter is the maximum number of records encrypted under The SNMAX parameter is the maximum number of records encrypted under
the same traffic key material (sender_write_key and sender_write_iv) the same traffic key material (sender_write_key and sender_write_iv)
and is defined by each cipher suite as follows: and is defined by each cipher suite as follows:
+------------------------------------------+--------------------+ +===========================================+==================+
| CipherSuites | SNMAX | | CipherSuites | SNMAX |
+------------------------------------------+--------------------+ +===========================================+==================+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L | SNMAX = 2^64 - 1 | | 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_MAGMA_MGM_L | SNMAX = 2^64 - 1 |
+------------------------------------------+--------------------+ +-------------------------------------------+------------------+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S | SNMAX = 2^42 - 1 | | TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S | SNMAX = 2^42 - 1 |
+------------------------------------------+--------------------+ +-------------------------------------------+------------------+
|TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | SNMAX = 2^39 - 1 | | TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | SNMAX = 2^39 - 1 |
+------------------------------------------+--------------------+ +-------------------------------------------+------------------+
Table 2
Table 2
4.2. Hash Algorithm 4.2. Hash Algorithm
The Hash algorithm is used for the key derivation process (see The Hash algorithm is used for the key derivation process (see
Section 7.1 of [RFC8446]), Finished message calculation (see Section 7.1 of [RFC8446]), Finished message calculation (see
Section 4.4.4 of [RFC8446]), Transcript-Hash function computation Section 4.4.4 of [RFC8446]), Transcript-Hash function computation
(see Section 4.4.1 of [RFC8446]), PSK binder value calculation (see (see Section 4.4.1 of [RFC8446]), Pre-Shared Key (PSK) binder value
Section 4.2.11.2 of [RFC8446]), external re-keying approach (see calculation (see Section 4.2.11.2 of [RFC8446]), external re-keying
Section 4.1.2) and other purposes. approach (see Section 4.1.2), and other purposes.
If a TLS13_GOST cipher suite is negotiated, the Hash algorithm MUST If a TLS13_GOST cipher suite is negotiated, the Hash algorithm MUST
be the GOST R 34.11-2012 hash algorithm [RFC6986] with 32-byte be the GOST R 34.11-2012 hash algorithm [RFC6986] with a 32-byte
(256-bit) hash value. (256-bit) hash value.
5. Signature Scheme Definition 5. Signature Scheme Definition
This section defines the following seven TLS13_GOST signature This section defines the following seven TLS13_GOST signature
schemes: schemes:
enum { enum {
gostr34102012_256a(0x0709), gostr34102012_256a(0x0709),
gostr34102012_256b(0x070A), gostr34102012_256b(0x070A),
gostr34102012_256c(0x070B), gostr34102012_256c(0x070B),
gostr34102012_256d(0x070C), gostr34102012_256d(0x070C),
gostr34102012_512a(0x070D), gostr34102012_512a(0x070D),
gostr34102012_512b(0x070E), gostr34102012_512b(0x070E),
gostr34102012_512c(0x070F) gostr34102012_512c(0x070F)
} SignatureScheme; } SignatureScheme;
One of the TLS13_GOST signature schemes listed above SHOULD be used One of the TLS13_GOST signature schemes listed above SHOULD be used
with the TLS13_GOST profile. with the TLS13_GOST profile.
Each signature scheme specifies a pair of the signature algorithm Each signature scheme specifies a pair consisting of the signature
(see Section 5.1) and the elliptic curve (see Section 5.2). The algorithm (see Section 5.1) and the elliptic curve (see Section 5.2).
procedure to calculate the signature value using TLS13_GOST signature The procedure to calculate the signature value using TLS13_GOST
schemes is defined in Section 5.3. signature schemes is defined in Section 5.3.
5.1. Signature Algorithm 5.1. Signature Algorithm
Signature algorithms corresponding to the TLS13_GOST signature Signature algorithms corresponding to the TLS13_GOST signature
schemes are defined as follows: schemes are defined as follows:
+------------------+--------------------------------------+--------+ +=======================+=====================+============+
| SignatureScheme | Signature Algorithm | Refe- | | SignatureScheme Value | Signature Algorithm | References |
| Value | | rences | +=======================+=====================+============+
+------------------+--------------------------------------+--------+ | gostr34102012_256a | GOST R 34.10-2012, | RFC 7091 |
|gostr34102012_256a|GOST R 34.10-2012 , 32-byte key length|RFC 7091| | | 32-byte key length | |
+------------------+--------------------------------------+--------+ +-----------------------+---------------------+------------+
|gostr34102012_256b|GOST R 34.10-2012 , 32-byte key length|RFC 7091| | gostr34102012_256b | GOST R 34.10-2012, | RFC 7091 |
+------------------+--------------------------------------+--------+ | | 32-byte key length | |
|gostr34102012_256c|GOST R 34.10-2012 , 32-byte key length|RFC 7091| +-----------------------+---------------------+------------+
+------------------+--------------------------------------+--------+ | gostr34102012_256c | GOST R 34.10-2012, | RFC 7091 |
|gostr34102012_256d|GOST R 34.10-2012 , 32-byte key length|RFC 7091| | | 32-byte key length | |
+------------------+--------------------------------------+--------+ +-----------------------+---------------------+------------+
|gostr34102012_512a|GOST R 34.10-2012 , 64-byte key length|RFC 7091| | gostr34102012_256d | GOST R 34.10-2012, | RFC 7091 |
+------------------+--------------------------------------+--------+ | | 32-byte key length | |
|gostr34102012_512b|GOST R 34.10-2012 , 64-byte key length|RFC 7091| +-----------------------+---------------------+------------+
+------------------+--------------------------------------+--------+ | gostr34102012_512a | GOST R 34.10-2012, | RFC 7091 |
|gostr34102012_512c|GOST R 34.10-2012 , 64-byte key length|RFC 7091| | | 64-byte key length | |
+------------------+--------------------------------------+--------+ +-----------------------+---------------------+------------+
Table 3 | gostr34102012_512b | GOST R 34.10-2012, | RFC 7091 |
| | 64-byte key length | |
+-----------------------+---------------------+------------+
| gostr34102012_512c | GOST R 34.10-2012, | RFC 7091 |
| | 64-byte key length | |
+-----------------------+---------------------+------------+
Table 3
5.2. Elliptic Curve 5.2. Elliptic Curve
Elliptic curves corresponding to the TLS13_GOST signature schemes are Elliptic curves corresponding to the TLS13_GOST signature schemes are
defined as follows: defined as follows:
+------------------+--------------------------------------+--------+ +=======================+=========================+============+
| SignatureScheme | Curve Identifier Value | Refe- | | SignatureScheme Value | Curve Identifier Value | References |
| Value | | rences | +=======================+=========================+============+
+------------------+--------------------------------------+--------+ | gostr34102012_256a | id-tc26-gost- | RFC 7836 |
|gostr34102012_256a| id-tc26-gost-3410-2012-256-paramSetA |RFC 7836| | | 3410-2012-256-paramSetA | |
+------------------+--------------------------------------+--------+ +-----------------------+-------------------------+------------+
|gostr34102012_256b|id-GostR3410-2001-CryptoPro-A-ParamSet|RFC 4357| | gostr34102012_256b | id-GostR3410-2001- | RFC 4357 |
+------------------+--------------------------------------+--------+ | | CryptoPro-A-ParamSet | |
|gostr34102012_256c|id-GostR3410-2001-CryptoPro-B-ParamSet|RFC 4357| +-----------------------+-------------------------+------------+
+------------------+--------------------------------------+--------+ | gostr34102012_256c | id-GostR3410-2001- | RFC 4357 |
|gostr34102012_256d|id-GostR3410-2001-CryptoPro-C-ParamSet|RFC 4357| | | CryptoPro-B-ParamSet | |
+------------------+--------------------------------------+--------+ +-----------------------+-------------------------+------------+
|gostr34102012_512a| id-tc26-gost-3410-12-512-paramSetA |RFC 7836| | gostr34102012_256d | id-GostR3410-2001- | RFC 4357 |
+------------------+--------------------------------------+--------+ | | CryptoPro-C-ParamSet | |
|gostr34102012_512b| id-tc26-gost-3410-12-512-paramSetB |RFC 7836| +-----------------------+-------------------------+------------+
+------------------+--------------------------------------+--------+ | gostr34102012_512a | id-tc26-gost- | RFC 7836 |
|gostr34102012_512c| id-tc26-gost-3410-2012-512-paramSetC |RFC 7836| | | 3410-12-512-paramSetA | |
+------------------+--------------------------------------+--------+ +-----------------------+-------------------------+------------+
Table 4 | gostr34102012_512b | id-tc26-gost- | RFC 7836 |
| | 3410-12-512-paramSetB | |
+-----------------------+-------------------------+------------+
| gostr34102012_512c | id-tc26-gost- | RFC 7836 |
| | 3410-2012-512-paramSetC | |
+-----------------------+-------------------------+------------+
5.3. SIGN function Table 4
5.3. SIGN Function
If the TLS13_GOST signature scheme is used, the signature value in If the TLS13_GOST signature scheme is used, the signature value in
the CertificateVerify message (see Section 6.3.4) MUST be calculated the CertificateVerify message (see Section 6.3.4) MUST be calculated
using the SIGN function defined as follows: using the SIGN function defined as follows:
+-----------------------------------------------------+ +-----------------------------------------------------+
| SIGN(d_sign, M) | | SIGN(d_sign, M) |
|-----------------------------------------------------| |-----------------------------------------------------|
| Input: | | Input: |
| - the sign key d_sign: 0 < d_sign < q; | | - the sign key d_sign: 0 < d_sign < q; |
| - the byte string M in B*. | | - the byte string M in B*. |
| Output: | | Output: |
| - signature value sgn in B_{2*l}. | | - signature value sgn in B_{2*l}. |
|-----------------------------------------------------| |-----------------------------------------------------|
| 1. (r, s) = SIGNGOST(d_sign, M) | | 1. (r, s) = SIGNGOST(d_sign, M) |
| 2. Return str_l(r) | str_l(s). | | 2. Return str_l(r) | str_l(s). |
|-----------------------------------------------------+ |-----------------------------------------------------+
where where
* q is the subgroup order of group of points of the elliptic curve; * q is the subgroup order of the group of points of the elliptic
curve;
* l is defined as follows: * l is defined as follows:
- l = 32 for the gostr34102012_256a, gostr34102012_256b, - l = 32 for the gostr34102012_256a, gostr34102012_256b,
gostr34102012_256c and gostr34102012_256d signature schemes; gostr34102012_256c, and gostr34102012_256d signature schemes;
- l = 64 for the gostr34102012_512a, gostr34102012_512b and - l = 64 for the gostr34102012_512a, gostr34102012_512b, and
gostr34102012_512c signature schemes; gostr34102012_512c signature schemes;
* SIGNGOST is an algorithm which takes a private key d_sign and a * SIGNGOST is an algorithm that takes a private key d_sign and a
message M as an input and returns a pair of integers (r, s) message M as an input and returns a pair of integers (r, s) that
calculated during signature generation process in accordance with is calculated during the signature generation process in
the GOST R 34.10-2012 signature algorithm (see Section 6.1 of accordance with the GOST R 34.10-2012 signature algorithm (see
[RFC7091]). Section 6.1 of [RFC7091]).
Note: The signature value sgn is the concatenation of two strings Note: The signature value sgn is the concatenation of two strings
that are byte representations of r and s values in the little-endian that are byte representations of r and s values in the little-endian
format. format.
6. Key Exchange and Authentication 6. Key Exchange and Authentication
Key exchange and authentication process in case of using the The key exchange and authentication process for using the TLS13_GOST
TLS13_GOST profile is defined in Section 6.1, Section 6.2 and profile is defined in Sections 6.1, 6.2, and 6.3.
Section 6.3.
6.1. Key Exchange 6.1. Key Exchange
TLS13_GOST profile supports three basic key exchange modes which are The TLS13_GOST profile supports three basic key exchange modes that
defined in [RFC8446]: ECDHE, PSK-only and PSK with ECDHE. 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 Note: In accordance with [RFC8446], TLS 1.3 also supports key
modes based on Diffie-Hellman protocol over finite fields. However, exchange modes based on the Diffie-Hellman protocol over finite
TLS13_GOST profile MUST use modes based on Diffie-Hellman protocol fields. However, the TLS13_GOST profile MUST use modes based on the
over elliptic curves. Diffie-Hellman protocol over elliptic curves.
In accordance with [RFC8446] PSKs can be divided into two types: In accordance with [RFC8446], PSKs can be divided into two types:
* internal PSKs which can be established during the previous * internal PSKs that can be established during the previous
connection; connection;
* external PSKs which can be established out of band. * external PSKs that can be established out of band.
If the TLS13_GOST profile is used, PSK-only key exchange mode SHOULD If the TLS13_GOST profile is used, PSK-only key exchange mode SHOULD
be established via the internal PSKs, and external PSKs SHOULD be be established via the internal PSKs, and external PSKs SHOULD be
used only in PSK with ECDHE mode (see more in Section 9). 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 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 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 in accordance with Section 6.1.1 on the basis of one of the elliptic
curves defined in Section 6.1.2. curves defined in Section 6.1.2.
6.1.1. ECDHE Shared Secret Calculation 6.1.1. ECDHE Shared Secret Calculation
If the TLS13_GOST profile is used, ECDHE shared secret SHOULD be If the TLS13_GOST profile is used, the ECDHE shared secret SHOULD be
calculated in accordance with Section 6.1.1.1 and Section 6.1.1.2. calculated in accordance with Sections 6.1.1.1 and 6.1.1.2. The
The public ephemeral keys used to obtain ECDHE shared secret SHOULD public ephemeral keys used to obtain the ECDHE shared secret SHOULD
be represented in the format described in Section 6.1.1.3. be represented in the format described in Section 6.1.1.3.
6.1.1.1. ECDHE Shared Secret Calculation on Client Side 6.1.1.1. ECDHE Shared Secret Calculation on the Client Side
The client calculates ECDHE shared secret in accordance with the The client calculates the ECDHE shared secret in accordance with the
following steps: following steps:
1. Chooses from all supported curves E_1, ..., E_R the set of curves Step 1. The client chooses from all supported curves E_1, ..., E_R
E_{i_1}, ..., E_{i_r}, 1 <= i_1 <= i_r <= R, where the set of curves E_{i_1}, ..., E_{i_r}, 1 <= i_1 <= i_r <=
R, where
* r >= 1 in case of the first ClientHello message; * r >= 1 in the case of the first ClientHello message;
* r = 1 in case of responding to the HelloRetryRequest message, * r = 1 in the case of responding to the HelloRetryRequest
E_{i_1} corresponds to the curve indicated in the "key_share" message; E_{i_1} corresponds to the curve indicated in
extension in the HelloRetryRequest message. the "key_share" extension in the HelloRetryRequest
message.
2. Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ..., Step 2. The client generates ephemeral key pairs (d_C^{i_1},
(d_C^{i_r}, Q_C^{i_r}) corresponding to the curves E_{i_1}, ..., Q_C^{i_1}), ..., (d_C^{i_r}, Q_C^{i_r}) corresponding to the
E_{i_r}, where for each i in {i_1, ..., i_r}: 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; * d_C^i is chosen from {1, ..., q_i - 1} at random;
* Q_C^i = d_C^i * P_i. * Q_C^i = d_C^i * P_i.
3. Sends the ClientHello message specified in accordance with Step 3. The client sends the ClientHello message specified in
Section 4.1.2 of [RFC8446] and Section 6.3.1, which contains: accordance with Section 4.1.2 of [RFC8446] and Section 6.3.1
that contains:
* "key_share" extension with public ephemeral keys Q_C^{i_1}, ..., * "key_share" extension with public ephemeral keys
Q_C^{i_r} built in accordance with Section 4.2.8 of [RFC8446]; Q_C^{i_1}, ..., Q_C^{i_r} built in accordance with
Section 4.2.8 of [RFC8446];
* "supported_groups" extension with supported curves E_1, ..., E_R * "supported_groups" extension with supported curves E_1,
built in accordance with Section 4.2.7 of [RFC8446]. ..., E_R built in accordance with Section 4.2.7 of
[RFC8446].
Note: The client MAY send an empty "key_share" extension in the first Note: The client MAY send an empty "key_share" extension
ClientHello message to request a group selection from the server in in the first ClientHello message to request a group
the HelloRetryRequest message and to generate an ephemeral key for selection from the server in the HelloRetryRequest
the selected group only. The ECDHE shared secret may be calculated message and to generate an ephemeral key for the selected
without sending HelloRetryRequest message, if the "key_share" group only. The ECDHE shared secret may be calculated
extension in the first ClientHello message contains the value without sending HelloRetryRequest message if the
corresponding to the curve that is selected by the server. "key_share" extension in the first ClientHello message
contains the value corresponding to the curve that is
selected by the server.
4. If the HelloRetryRequest message is received, the client MUST Step 4. If the HelloRetryRequest message is received, the client
return to step 1 and choose correct parameters in accordance with MUST return to Step 1 and choose correct parameters in
Section 4.1.2 of [RFC8446]. If the ServerHello message is received, accordance with Section 4.1.2 of [RFC8446]. If the
the client proceeds to the next step. In other cases, the client ServerHello message is received, the client proceeds to the
MUST terminate the connection with the "unexpected_message" alert. next step. In other cases, the client MUST terminate the
connection with the "unexpected_message" alert.
5. Extracts curve E_res and ephemeral key Q_S^res, res in {1, ..., Step 5. The client extracts curve E_res and ephemeral key Q_S^res,
R}, from the ServerHello message and checks whether Q_S^res belongs res in {1, ..., R}, from the ServerHello message and checks
to E_res. If this check fails, the client MUST terminate the whether Q_S^res belongs to E_res. If this check fails, the
connection with "handshake_failure" alert. client MUST terminate the connection with
"handshake_failure" alert.
6. Generates Q^ECDHE: Step 6. The client generates Q^ECDHE:
Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) * Q_S^res. Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) *
Q_S^res.
7. The client MUST check whether the calculated shared secret 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, Q^ECDHE is not equal to the zero point O_res. If this check
the client MUST terminate the connection with "handshake_failure" fails, the client MUST terminate the connection with
alert. "handshake_failure" alert.
8. The ECDHE shared secret is the byte representation of the 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: coordinate X^ECDHE of the point Q^ECDHE in the little-endian
format:
ECDHE = str_{coordinate_length}(X^ECDHE), ECDHE = str_{coordinate_length}(X^ECDHE),
where the coordinate_length value is defined by the particular where the coordinate_length value is defined by the
elliptic curve (see Section 6.1.2). particular elliptic curve (see Section 6.1.2).
6.1.1.2. ECDHE Shared Secret Calculation on Server Side 6.1.1.2. ECDHE Shared Secret Calculation on Server Side
Upon receiving the ClientHello message, the server calculates ECDHE Upon receiving the ClientHello message, the server calculates the
shared secret in accordance with the following steps: ECDHE shared secret in accordance with the following steps:
1. Chooses the curve E_res, res in {1, ..., R}, from the list of the Step 1. The server chooses the curve E_res, res in {1, ..., R}, from
curves E_1, ..., E_R indicated in the "supported_groups" extension in the list of the curves E_1, ..., E_R indicated in the
the ClientHello message and the corresponding public ephemeral key "supported_groups" extension in the ClientHello message and
Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r}, 1 <= i_1 <= i_r <= the corresponding public ephemeral key Q_C^res from the list
R, indicated in the "key_share" extension. If the corresponding Q_C^{i_1}, ..., Q_C^{i_r}, 1 <= i_1 <= i_r <= R, indicated
public ephemeral key is not found (res in {1, ..., R}\{i_1, ..., in the "key_share" extension. If the corresponding public
i_r}), the server MUST send the HelloRetryRequest message with the ephemeral key is not found (res in {1, ..., R}\{i_1, ...,
"key_share" extension indicating the selected elliptic curve E_res i_r}), the server MUST send the HelloRetryRequest message
and wait for the new ClientHello message. with the "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, Step 2. The server checks whether Q_C^res belongs to E_res. If this
the server MUST terminate the connection with "handshake_failure" check fails, the server MUST terminate the connection with
alert. "handshake_failure" alert.
3. Generates ephemeral key pair (d_S^res, Q_S^res) corresponding to Step 3. The server generates ephemeral key pair (d_S^res, Q_S^res)
E_res: corresponding to E_res:
* d_S^res is chosen from {1, ..., q_res - 1} at random; * d_S^res is chosen from {1, ..., q_res - 1} at random;
* Q_S^res = d_S^res * P_res. * Q_S^res = d_S^res * P_res.
4. Sends the ServerHello message generated in accordance with Step 4. The server sends the ServerHello message generated in
Section 4.1.3 of [RFC8446] and Section 6.3.1 with the "key_share" accordance with Section 4.1.3 of [RFC8446] and Section 6.3.1
extension which contains public ephemeral key Q_S^res corresponding with the "key_share" extension that contains public
to E_res. ephemeral key Q_S^res corresponding to E_res.
5. Generates Q^ECDHE: Step 5. The server generates Q^ECDHE:
Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res. Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) *
Q_C^res.
6. The server MUST check whether the calculated shared secret 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, Q^ECDHE is not equal to the zero point O_res. If this check
the server MUST abort the handshake with "handshake_failure" alert. fails, the server MUST abort the handshake with
"handshake_failure" alert.
7. The ECDHE shared secret is the byte representation of the 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: coordinate X^ECDHE of the point Q^ECDHE in the little-endian
format:
ECDHE = str_{coordinate_length}(X^ECDHE), ECDHE = str_{coordinate_length}(X^ECDHE),
where the coordinate_length value is defined by the particular where the coordinate_length value is defined by the
elliptic curve (see Section 6.1.2). particular elliptic curve (see Section 6.1.2).
6.1.1.3. Public ephemeral key representation 6.1.1.3. Public Ephemeral Key Representation
This section defines the representation format of the public This section defines the representation format of the public
ephemeral keys generated during the ECDHE shared secret calculation ephemeral keys generated during the ECDHE shared secret calculation
(see Section 6.1.1.1 and Section 6.1.1.2). (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 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 exchange mode is used, the public ephemeral key Q indicated in the
KeyShareEntry.key_exchange field MUST contain the data defined by the KeyShareEntry.key_exchange field MUST contain the data defined by the
following structure: following structure:
struct { struct {
opaque X[coordinate_length]; opaque X[coordinate_length];
opaque Y[coordinate_length]; opaque Y[coordinate_length];
} PlainPointRepresentation; } PlainPointRepresentation;
where X and Y, respectively, contain the byte representations of x 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 y values of the point Q (Q = (x, y)) in the little-endian format
and are specified as follows: and are specified as follows:
X = str_{coordinate_length}(x); * X = str_{coordinate_length}(x);
Y = str_{coordinate_length}(y). * Y = str_{coordinate_length}(y).
The coordinate_length value is defined by the particular elliptic The coordinate_length value is defined by the particular elliptic
curve (see Section 6.1.2). curve (see Section 6.1.2).
6.1.2. Values for the TLS Supported Groups Registry 6.1.2. Values for the TLS Supported Groups Registry
The "supported_groups" extension is used to indicate the set of the The "supported_groups" extension is used to indicate the set of the
elliptic curves supported by an endpoint and is defined in elliptic curves supported by an endpoint and is defined in
Section 4.2.7 [RFC8446]. This extension is always contained in the Section 4.2.7 of [RFC8446]. This extension is always contained in
ClientHello message and optionally in the EncryptedExtensions the ClientHello message and optionally in the EncryptedExtensions
message. message.
This section defines the following seven elliptic curves: This section defines the following seven elliptic curves:
enum { enum {
GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25), GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25),
GC512A(0x26), GC512B(0x27), GC512C(0x28) GC512A(0x26), GC512B(0x27), GC512C(0x28)
} NamedGroup; } NamedGroup;
If the TLS13_GOST profile is used and ECDHE or PSK with ECDHE key 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 exchange mode is used, one of the elliptic curves listed above SHOULD
be used. be used.
Each curve corresponds to the particular identifier and specifies the Each curve corresponds to the particular identifier and specifies the
value of coordinate_length parameter (see "cl" column) as follows: value of coordinate_length parameter (see "cl" column) as follows:
+-----------+--------------------------------------+----+---------+ +===========+========================================+==+=========+
|Description| Curve Identifier Value | cl |Reference| |Description| Curve Identifier Value |cl|Reference|
+-----------+--------------------------------------+----+---------+ +===========+========================================+==+=========+
| GC256A | id-tc26-gost-3410-2012-256-paramSetA | 32 | RFC 7836| |GC256A | id-tc26-gost-3410-2012-256-paramSetA |32|RFC 7836 |
+-----------+--------------------------------------+----+---------+ +-----------+----------------------------------------+--+---------+
| GC256B |id-GostR3410-2001-CryptoPro-A-ParamSet| 32 | RFC 4357| |GC256B | id-GostR3410-2001-CryptoPro-A-ParamSet |32|RFC 4357 |
+-----------+--------------------------------------+----+---------+ +-----------+----------------------------------------+--+---------+
| GC256C |id-GostR3410-2001-CryptoPro-B-ParamSet| 32 | RFC 4357| |GC256C | id-GostR3410-2001-CryptoPro-B-ParamSet |32|RFC 4357 |
+-----------+--------------------------------------+----+---------+ +-----------+----------------------------------------+--+---------+
| GC256D |id-GostR3410-2001-CryptoPro-C-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| |GC512A | id-tc26-gost-3410-12-512-paramSetA |64|RFC 7836 |
+-----------+--------------------------------------+----+---------+ +-----------+----------------------------------------+--+---------+
| GC512B | id-tc26-gost-3410-12-512-paramSetB | 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| |GC512C | id-tc26-gost-3410-2012-512-paramSetC |64|RFC 7836 |
+-----------+--------------------------------------+----+---------+ +-----------+----------------------------------------+--+---------+
Table 5
Table 5
Note: The identifier values and the corresponding elliptic curves are Note: The identifier values and the corresponding elliptic curves are
the same as in [RFC9189]. the same as in [RFC9189].
6.2. Authentication 6.2. Authentication
In accordance with [RFC8446], authentication can be performed via a In accordance with [RFC8446], authentication can be performed via a
signature with a certificate or via a symmetric pre-shared key (PSK). signature with a certificate or via a symmetric PSK. The server side
The server side is always authenticated; the client side is is always authenticated; the client side is optionally authenticated.
optionally authenticated.
PSK-based authentication is performed as a side effect of key PSK-based authentication is performed as a side effect of key
exchange. If the TLS13_GOST profile is used, external PSKs SHOULD be exchange. If the TLS13_GOST profile is used, external PSKs SHOULD be
combined only with the mutual authentication (see more in Section 9). combined only with mutual authentication (see Section 9).
Certificate-based authentication is performed via Authentication Certificate-based authentication is performed via Authentication
messages and optional CertificateRequest message (sent if client messages and an optional CertificateRequest message (sent if client
authentication is required). If the TLS13_GOST profile is used, the authentication is required). If the TLS13_GOST profile is used, the
signature schemes used for certificate-based authentication are signature schemes used for certificate-based authentication are
defined in Section 5 and Authentication messages are specified in defined in Section 5 and Authentication messages are specified in
Section 6.3.3 and Section 6.3.4. The CertificateRequest message is Sections 6.3.3 and 6.3.4. The CertificateRequest message is
specified in Section 6.3.2. specified in Section 6.3.2.
6.3. Handshake Messages 6.3. Handshake Messages
The TLS13_GOST profile specifies the ClientHello, ServerHello, The TLS13_GOST profile specifies the ClientHello, ServerHello,
CertificateRequest, Certificate and CertificateVerify handshake CertificateRequest, Certificate and CertificateVerify handshake
messages that are described in further detail below. messages that are described in further detail below.
6.3.1. Hello Messages 6.3.1. Hello Messages
The ClientHello message is sent when the client first connects to the The ClientHello message is sent when the client first connects to the
server or responds to the HelloRetryRequest message and is specified server or responds to the HelloRetryRequest message and is specified
in accordance with Section 4.1.2 of [RFC8446]. in accordance with Section 4.1.2 of [RFC8446].
If the TLS13_GOST profile is used, the ClientHello message MUST meet If the TLS13_GOST profile is used, the ClientHello message MUST meet
the following requirements. the following requirements:
* The ClientHello.cipher_suites field MUST contain the values * The ClientHello.cipher_suites field MUST contain the values
defined in Section 4. defined in Section 4.
* If server authentication via a certificate is required, the * If server authentication via a certificate is required, the
extension_data field of the "signature_algorithms" extension MUST extension_data field of the "signature_algorithms" extension MUST
contain the values defined in Section 5, which correspond to the contain the values defined in Section 5 that correspond to the
GOST R 34.10-2012 signature algorithm. GOST R 34.10-2012 signature algorithm.
* If server authentication via a certificate is required and the * If server authentication via a certificate is required and the
client uses optional "signature_algorithms_cert" extension, the client uses optional "signature_algorithms_cert" extension, the
extension_data field of this extension SHOULD contain the values extension_data field of this extension SHOULD contain the values
defined in Section 5, which correspond to the GOST R 34.10-2012 defined in Section 5 that correspond to the GOST R 34.10-2012
signature algorithm. signature algorithm.
* If the client wants to establish a TLS 1.3 connection using ECDHE * If the client wants to establish a TLS 1.3 connection using the
shared secret, the extension_data field of the "supported_groups" ECDHE shared secret, the extension_data field of the
extension MUST contain the elliptic curve identifiers defined in "supported_groups" extension MUST contain the elliptic curve
Section 6.1.2. identifiers defined in Section 6.1.2.
The ServerHello message is sent by the server in response to the The ServerHello message is sent by the server in response to the
ClientHello message to negotiate an acceptable set of handshake ClientHello message to negotiate an acceptable set of handshake
parameters based on the ClientHello message and is specified in parameters based on the ClientHello message and is specified in
accordance with Section 4.1.3 of [RFC8446]. accordance with Section 4.1.3 of [RFC8446].
If the TLS13_GOST profile is used, the ServerHello message MUST meet If the TLS13_GOST profile is used, the ServerHello message MUST meet
the following requirements. the following requirements:
* The ServerHello.cipher_suite field MUST contain one of the values * The ServerHello.cipher_suite field MUST contain one of the values
defined in Section 4. defined in Section 4.
* If the server decides to establish a TLS 1.3 connection using * If the server decides to establish a TLS 1.3 connection using the
ECDHE shared secret, the extension_data field of the "key_share" ECDHE shared secret, the extension_data field of the "key_share"
extension MUST contain the elliptic curve identifier and the extension MUST contain the elliptic curve identifier and the
public ephemeral key that satisfy the following conditions. public ephemeral key that satisfy the following conditions:
- The elliptic curve identifier corresponds to the value that was - The elliptic curve identifier corresponds to the value that was
indicated in the "supported_groups" and the "key_share" indicated in the "supported_groups" and the "key_share"
extensions in the ClientHello message. extensions in the ClientHello message.
- The elliptic curve identifier is one of the values defined in - The elliptic curve identifier is one of the values defined in
Section 6.1.2. Section 6.1.2.
- The public ephemeral key corresponds to the elliptic curve - The public ephemeral key corresponds to the elliptic curve
specified by the KeyShareEntry.group identifier. specified by the KeyShareEntry.group identifier.
6.3.2. CertificateRequest 6.3.2. CertificateRequest
This message is sent when the server requests client authentication This message is sent when the server requests client authentication
via a certificate and is specified in accordance with Section 4.3.2 via a certificate and is specified in accordance with Section 4.3.2
of [RFC8446]. of [RFC8446].
If the TLS13_GOST profile is used, the CertificateRequest message If the TLS13_GOST profile is used, the CertificateRequest message
MUST meet the following requirements. MUST meet the following requirements:
* The extension_data field of the "signature_algorithms" extension * The extension_data field of the "signature_algorithms" extension
MUST contain only the values defined in Section 5. MUST contain only the values defined in Section 5.
* If the server uses optional "signature_algorithms_cert" extension, * If the server uses optional "signature_algorithms_cert" extension,
the extension_data field of this extension SHOULD contain only the the extension_data field of this extension SHOULD contain only the
values defined in Section 5. values defined in Section 5.
6.3.3. Certificate 6.3.3. Certificate
This message is sent to convey the endpoint's certificate chain to 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 the peer and is specified in accordance with Section 4.4.2 of
[RFC8446]. [RFC8446].
If the TLS13_GOST profile is used, the Certificate message MUST meet If the TLS13_GOST profile is used, the Certificate message MUST meet
the following requirements. the following requirements.
* Each endpoint's certificate provided to the peer MUST be signed * Each endpoint's certificate provided to the peer MUST be signed
using the algorithm which corresponds to a signature scheme using the algorithm that corresponds to a signature scheme
indicated by the peer in its "signature_algoritms_cert" extension, indicated by the peer in its "signature_algorithms_cert"
if present (or in the "signature_algorithms" extension, extension, if present (or in the "signature_algorithms" extension,
otherwise). otherwise).
* The signature algorithm used for signing certificates SHOULD * The signature algorithm used for signing certificates SHOULD
correspond to one of the signature schemes defined in Section 5. correspond to one of the signature schemes defined in Section 5.
6.3.4. CertificateVerify 6.3.4. CertificateVerify
This message is sent to provide explicit proof that the endpoint has This message is sent to provide explicit proof that the endpoint has
the private key corresponding to the public key indicated in its the private key corresponding to the public key indicated in its
certificate and is specified in accordance with Section 4.4.3 of certificate and is specified in accordance with Section 4.4.3 of
[RFC8446]. [RFC8446].
If the TLS13_GOST profile is used, the CertificateVerify message MUST If the TLS13_GOST profile is used, the CertificateVerify message MUST
meet the following requirements. meet the following requirements:
* The CertificateVerify.algorithm field MUST contain the signature * The CertificateVerify.algorithm field MUST contain the signature
scheme identifier which corresponds to the value indicated in the scheme identifier that corresponds to the value indicated in the
peer's "signature_algorithms" extension and which is one of the peer's "signature_algorithms" extension and is one of the values
values defined in Section 5. defined in Section 5.
* The CertificateVerify.signature field contains the sgn value, * The CertificateVerify.signature field contains the sgn value that
which is computed as follows: is computed as follows:
sgn = SIGN(d_sign, M), sgn = SIGN(d_sign, M),
where where
- the SIGN function is defined in Section 5.3, - the SIGN function is defined in Section 5.3;
- d_sign is the sender's long-term private key that corresponds - d_sign is the sender's long-term private key that corresponds
to the sender's long-term public key Q_sign from the sender's to the sender's long-term public key Q_sign from the sender's
certificate, certificate;
- the message M is defined in accordance with Section 4.4.3 of - the message M is defined in accordance with Section 4.4.3 of
[RFC8446]. [RFC8446].
7. IANA Considerations 7. IANA Considerations
IANA has added the following values to the "TLS Cipher Suites" IANA has added the following values to the "TLS Cipher Suites"
registry: registry with a reference to this RFC:
+----------+-----------------------------+-------+-------------+-----------+ +=====+=========================================+=======+===========+
| Value | Description |DTLS-OK| Recommended | Reference | |Value|Description |DTLS-OK|Recommended|
+----------+-----------------------------+-------+-------------+-----------+ +=====+=========================================+=======+===========+
|0xC1, 0x03| TLS_GOSTR341112_256_ | N | N | this RFC | |0xC1,|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L|N |N |
| | _WITH_KUZNYECHIK_MGM_L | | | | |0x03 | | | |
+----------+-----------------------------+-------+-------------+-----------+ +-----+-----------------------------------------+-------+-----------+
|0xC1, 0x04| TLS_GOSTR341112_256_ | N | N | this RFC | |0xC1,|TLS_GOSTR341112_256_WITH_MAGMA_MGM_L |N |N |
| | _WITH_MAGMA_MGM_L | | | | |0x04 | | | |
+----------+-----------------------------+-------+-------------+-----------+ +-----+-----------------------------------------+-------+-----------+
|0xC1, 0x05| TLS_GOSTR341112_256_ | N | N | this RFC | |0xC1,|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S|N |N |
| | _WITH_KUZNYECHIK_MGM_S | | | | |0x05 | | | |
+----------+-----------------------------+-------+-------------+-----------+ +-----+-----------------------------------------+-------+-----------+
|0xC1, 0x06| TLS_GOSTR341112_256_ | N | N | this RFC | |0xC1,|TLS_GOSTR341112_256_WITH_MAGMA_MGM_S |N |N |
| | _WITH_MAGMA_MGM_S | | | | |0x06 | | | |
+----------+-----------------------------+-------+-------------+-----------+ +-----+-----------------------------------------+-------+-----------+
Table 6
Table 6
IANA has added the following values to the "TLS SignatureScheme" IANA has added the following values to the "TLS SignatureScheme"
registry: registry with a reference to this RFC:
+-----------+----------------------+---------------+----------+ +========+====================+=============+
| Value | Description | Recommended | Reference| | Value | Description | Recommended |
+-----------+----------------------+---------------+----------+ +========+====================+=============+
| 0x0709 | gostr34102012_256a | N | this RFC | | 0x0709 | gostr34102012_256a | N |
+-----------+----------------------+---------------+----------+ +--------+--------------------+-------------+
| 0x070A | gostr34102012_256b | N | this RFC | | 0x070A | gostr34102012_256b | N |
+-----------+----------------------+---------------+----------+ +--------+--------------------+-------------+
| 0x070B | gostr34102012_256c | N | this RFC | | 0x070B | gostr34102012_256c | N |
+-----------+----------------------+---------------+----------+ +--------+--------------------+-------------+
| 0x070C | gostr34102012_256d | N | this RFC | | 0x070C | gostr34102012_256d | N |
+-----------+----------------------+---------------+----------+ +--------+--------------------+-------------+
| 0x070D | gostr34102012_512a | N | this RFC | | 0x070D | gostr34102012_512a | N |
+-----------+----------------------+---------------+----------+ +--------+--------------------+-------------+
| 0x070E | gostr34102012_512b | N | this RFC | | 0x070E | gostr34102012_512b | N |
+-----------+----------------------+---------------+----------+ +--------+--------------------+-------------+
| 0x070F | gostr34102012_512c | N | this RFC | | 0x070F | gostr34102012_512c | N |
+-----------+----------------------+---------------+----------+ +--------+--------------------+-------------+
Table 7
8. Historical considerations Table 7
Due to historical reasons in addition to the curve identifier values 8. Historical Considerations
listed in Table 5 there exist some additional identifier values that
correspond to the signature schemes as follows.
+--------------------+-------------------------------------------+ In addition to the curve identifier values listed in Table 5, there
| Description | Curve Identifier Value | are some additional identifier values that correspond to the
+--------------------+-------------------------------------------+ signature schemes for historical reasons. They are as follows:
| 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 +====================+============================================+
| 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
The client should be prepared to handle any of them correctly if the
corresponding signature scheme is included in the corresponding signature scheme is included in the
"signature_algorithms" or "signature_algorithms_cert" extensions. "signature_algorithms" or "signature_algorithms_cert" extensions.
9. Security Considerations 9. Security Considerations
In order to create an efficient and side-channel resistant In order to create an efficient and side-channel resistant
implementation, while using the TLSTREE algorithm the functions implementation while using the TLSTREE algorithm, the functions
KDF_j, j = 1, 2, 3, SHOULD be called only when necessary (when the 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 record sequence number seqnum reaches such a value that seqnum & C_j
!= (seqnum - 1) & C_j). Otherwise the previous value should be used. != (seqnum - 1) & C_j). Otherwise, the previous value should be
used.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:
Hash Function", RFC 6986, DOI 10.17487/RFC6986, August Hash Function", RFC 6986, DOI 10.17487/RFC6986, August
2013, <https://www.rfc-editor.org/info/rfc6986>. 2013, <https://www.rfc-editor.org/rfc/rfc6986>.
[RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012:
Digital Signature Algorithm", RFC 7091, Digital Signature Algorithm", RFC 7091,
DOI 10.17487/RFC7091, December 2013, DOI 10.17487/RFC7091, December 2013,
<https://www.rfc-editor.org/info/rfc7091>. <https://www.rfc-editor.org/rfc/rfc7091>.
[RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher
"Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016,
<https://www.rfc-editor.org/info/rfc7801>. <https://www.rfc-editor.org/rfc/rfc7801>.
[RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V.,
Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines
on the Cryptographic Algorithms to Accompany the Usage of on the Cryptographic Algorithms to Accompany the Usage of
Standards GOST R 34.10-2012 and GOST R 34.11-2012", Standards GOST R 34.10-2012 and GOST R 34.11-2012",
RFC 7836, DOI 10.17487/RFC7836, March 2016, RFC 7836, DOI 10.17487/RFC7836, March 2016,
<https://www.rfc-editor.org/info/rfc7836>. <https://www.rfc-editor.org/rfc/rfc7836>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric [RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric
Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019,
<https://www.rfc-editor.org/info/rfc8645>. <https://www.rfc-editor.org/rfc/rfc8645>.
[RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015: [RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015:
Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891, Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891,
September 2020, <https://www.rfc-editor.org/info/rfc8891>. September 2020, <https://www.rfc-editor.org/rfc/rfc8891>.
[RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E. [RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E.
Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058, Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058,
DOI 10.17487/RFC9058, June 2021, DOI 10.17487/RFC9058, June 2021,
<https://www.rfc-editor.org/info/rfc9058>. <https://www.rfc-editor.org/rfc/rfc9058>.
[RFC9189] Smyshlyaev, S., Ed., Belyavsky, D., and E. Alekseev, "GOST [RFC9189] Smyshlyaev, S., Ed., Belyavsky, D., and E. Alekseev, "GOST
Cipher Suites for Transport Layer Security (TLS) Protocol Cipher Suites for Transport Layer Security (TLS) Protocol
Version 1.2", RFC 9189, DOI 10.17487/RFC9189, March 2022, Version 1.2", RFC 9189, DOI 10.17487/RFC9189, March 2022,
<https://www.rfc-editor.org/info/rfc9189>. <https://www.rfc-editor.org/rfc/rfc9189>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-tls-rfc8446bis] [RFC8446BIS]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft- Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-04, 7 March 2022, ietf-tls-rfc8446bis-05, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-04>. rfc8446bis-05>.
Appendix A. Test Examples Appendix A. Test Examples
A.1. Example 1 A.1. Example 1
A.1.1. Test case
Test examples are given for the following order of using the A.1.1. Test Case
TLS13_GOST profile.
Test examples are given for the following instance of the TLS13_GOST
profile:
1. Full TLS Handshake is used. 1. Full TLS Handshake is used.
2. ECDHE key exchange mode is used. The elliptic curve GC512C is 2. ECDHE key exchange mode is used. The elliptic curve GC512C is
used for ECDHE shared secret calculation. used for ECDHE shared secret calculation.
3. The server side only authentication is used. The signature 3. Authentication is only used on the server side. The signature
scheme gost34102012_256b is used. scheme gost34102012_256b is used.
4. TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S cipher suite is 4. TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S cipher suite is
negotiated. negotiated.
5. Application Data is sent by the server prior to receiving the 5. Application Data is sent by the server prior to receiving the
Finished message from the client. Finished message from the client.
6. NewSessionTicket is sent after establishing a secure connection. 6. NewSessionTicket is sent after establishing a secure connection.
7. Nine Application Data records are sent during the operation of 7. Nine Application Data records are sent during the operation of
the Record protocol. The sequence numbers are selected to the Record protocol. The sequence numbers are selected to
demonstrate the operation of the TLSTREE function. demonstrate the operation of the TLSTREE function.
8. Alert protocol is used for closure of the connection. 8. Alert protocol is used for closure of the connection.
A.1.2. Test examples A.1.2. Test Examples
---------------------------Client--------------------------- ---------------------------Client---------------------------
ClientHello message: ClientHello message:
msg_type: 01 msg_type: 01
length: 0000DE length: 0000DE
body: body:
legacy_version: 0303 legacy_version: 0303
random: 03030303030303030303030303030303 random: 03030303030303030303030303030303
03030303030303030303030303030303 03030303030303030303030303030303
legasy_session_id: legacy_session_id:
length: 00 length: 00
vector: -- vector: --
cipher_suites: cipher_suites:
length: 0002 length: 0002
vector: vector:
CipherSuite: C105 CipherSuite: C105
compression_methods: compression_methods:
length: 01 length: 01
vector: vector:
CompressionMethod: 00 CompressionMethod: 00
extensions: extensions:
length: 00B3 length: 00B3
vector: vector:
Extension: /* supported_groups */ Extension: /* supported_groups */
extension_type: 000A extension_type: 000A
extension_data: extension_data:
length: 0004 length: 0004
skipping to change at page 28, line 47 skipping to change at line 1338
---------------------------Server--------------------------- ---------------------------Server---------------------------
ServerHello message: ServerHello message:
msg_type: 02 msg_type: 02
length: 0000B6 length: 0000B6
body: body:
legacy_version: 0303 legacy_version: 0303
random: 83838383838383838383838383838383 random: 83838383838383838383838383838383
83838383838383838383838383838383 83838383838383838383838383838383
legasy_session_id: legacy_session_id:
length: 00 length: 00
vector: -- vector: --
cipher_suite: cipher_suite:
CipherSuite: C105 CipherSuite: C105
compression_method: compression_method:
CompressionMethod: 00 CompressionMethod: 00
extensions: extensions:
length: 008E length: 008E
vector: vector:
Extension: /* supported_versions */ Extension: /* supported_versions */
extension_type: 002B extension_type: 002B
extension_data: extension_data:
length: 0002 length: 0002
vector: vector:
skipping to change at page 59, line 4 skipping to change at line 2785
00000: B8 2D 78 25 D1 5F AE 18 A7 01 32 28 B3 1C B0 C5 00000: B8 2D 78 25 D1 5F AE 18 A7 01 32 28 B3 1C B0 C5
00010: 97 52 C6 40 9C 5F 78 99 EC C6 95 0F 74 63 C0 90 00010: 97 52 C6 40 9C 5F 78 99 EC C6 95 0F 74 63 C0 90
seqnum: seqnum:
00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A
nonce: nonce:
00000: 31 09 57 EF 71 31 44 33 F5 76 CC 9B 00 AD 93 5E 00000: 31 09 57 EF 71 31 44 33 F5 76 CC 9B 00 AD 93 5E
additional_data: additional_data:
00000: 17 03 03 00 13 00000: 17 03 03 00 13
TLSInnerPlaintext: TLSInnerPlaintext:
00000: 01 00 15 00000: 01 00 15
Record layer message: Record layer message:
type: 17 type: 17
legacy_record_version: 0303 legacy_record_version: 0303
length: 0013 length: 0013
encrypted_record: CB19F306C3641754BE4FC95390DF06F9 encrypted_record: CB19F306C3641754BE4FC95390DF06F9
CD44AA CD44AA
TLSCiphertext: TLSCiphertext:
00000: 17 03 03 00 13 CB 19 F3 06 C3 64 17 54 BE 4F C9 00000: 17 03 03 00 13 CB 19 F3 06 C3 64 17 54 BE 4F C9
00010: 53 90 DF 06 F9 CD 44 AA 00010: 53 90 DF 06 F9 CD 44 AA
A.2. Example 2 A.2. Example 2
A.2.1. Test case A.2.1. Test Case
Test examples are given for the following order of using the Test examples are given for the following instance of the TLS13_GOST
TLS13_GOST profile. profile:
1. Full TLS Handshake is used. 1. Full TLS Handshake is used.
2. PSK with ECDHE key exchange mode is used. The elliptic curve 2. PSK with ECDHE key exchange mode is used. The elliptic curve
GC256B is used for ECDHE shared secret calculation. GC256B is used for ECDHE shared secret calculation.
3. The server and client sides authentication is used. The external 3. Authentication is used on the server and client sides. The
PSK is used for the mutual authentication. external PSK is used for the mutual authentication.
4. TLS_GOSTR341112_256_WITH_MAGMA_MGM_L cipher suite is negotiated. 4. TLS_GOSTR341112_256_WITH_MAGMA_MGM_L cipher suite is negotiated.
5. Four Application Data records are sent during the operation of 5. Four Application Data records are sent during the operation of
the Record protocol. The sequence numbers are selected to the Record protocol. The sequence numbers are selected to
demonstrate the operation of the TLSTREE function. demonstrate the operation of the TLSTREE function.
6. Alert protocol is used for closure of the connection. 6. Alert protocol is used for closure of the connection.
A.2.2. Test examples A.2.2. Test Examples
ePSK: ePSK:
00000: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 00000: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
00000: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 00000: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
---------------------------Client--------------------------- ---------------------------Client---------------------------
ClientHello1 message: ClientHello1 message:
msg_type: 01 msg_type: 01
length: 00007B length: 00007B
body: body:
legacy_version: 0303 legacy_version: 0303
random: 01010101010101010101010101010101 random: 01010101010101010101010101010101
01010101010101010101010101010101 01010101010101010101010101010101
legasy_session_id: legacy_session_id:
length: 00 length: 00
vector: -- vector: --
cipher_suites: cipher_suites:
length: 0002 length: 0002
vector: vector:
CipherSuite: C104 CipherSuite: C104
compression_methods: compression_methods:
length: 01 length: 01
vector: vector:
CompressionMethod: 00 CompressionMethod: 00
skipping to change at page 63, line 4 skipping to change at line 2975
00000: 16 03 01 00 7F 01 00 00 7B 03 03 01 01 01 01 01 00000: 16 03 01 00 7F 01 00 00 7B 03 03 01 01 01 01 01
00010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00010: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
00020: 01 01 01 01 01 01 01 01 01 01 01 00 00 02 C1 04 00020: 01 01 01 01 01 01 01 01 01 01 01 00 00 02 C1 04
00030: 01 00 00 50 00 0A 00 06 00 04 00 23 00 28 00 2B 00030: 01 00 00 50 00 0A 00 06 00 04 00 23 00 28 00 2B
00040: 00 03 02 03 04 0A 07 0B 07 0C 07 0D 07 0E 07 0F 00040: 00 03 02 03 04 0A 07 0B 07 0C 07 0D 07 0E 07 0F
00050: 00 2B 00 03 02 00 2D 00 02 01 01 00 33 00 02 00 00050: 00 2B 00 03 02 00 2D 00 02 01 01 00 33 00 02 00
00060: 00 00 29 00 2F 00 0A 00 04 65 50 53 4B 00 00 00 00060: 00 00 29 00 2F 00 0A 00 04 65 50 53 4B 00 00 00
00070: 00 00 21 20 6F 3A 0B 91 F2 94 5E F7 05 6D B7 43 00070: 00 00 21 20 6F 3A 0B 91 F2 94 5E F7 05 6D B7 43
00080: 02 BC 34 B6 DF 77 A8 8E 09 C5 87 50 8A B6 28 7C 00080: 02 BC 34 B6 DF 77 A8 8E 09 C5 87 50 8A B6 28 7C
00090: 6C 05 14 AD 00090: 6C 05 14 AD
---------------------------Server--------------------------- ---------------------------Server---------------------------
HelloRetryRequest message: HelloRetryRequest message:
msg_type: 02 msg_type: 02
length: 000034 length: 000034
body: body:
legacy_version: 0303 legacy_version: 0303
random: CF21AD74E59A6111BE1D8C021E65B891 random: CF21AD74E59A6111BE1D8C021E65B891
C2A211167ABB8C5E079E09E2C8A8339C C2A211167ABB8C5E079E09E2C8A8339C
legasy_session_id: legacy_session_id:
length: 00 length: 00
vector: -- vector: --
cipher_suite: cipher_suite:
CipherSuite: C104 CipherSuite: C104
compression_method: compression_method:
CompressionMethod: 00 CompressionMethod: 00
extensions: extensions:
length: 000C length: 000C
vector: vector:
Extension: /* supported_versions */ Extension: /* supported_versions */
skipping to change at page 64, line 16 skipping to change at line 3036
---------------------------Client--------------------------- ---------------------------Client---------------------------
ClientHello2 message: ClientHello2 message:
msg_type: 01 msg_type: 01
length: 0000BF length: 0000BF
body: body:
legacy_version: 0303 legacy_version: 0303
random: 01010101010101010101010101010101 random: 01010101010101010101010101010101
01010101010101010101010101010101 01010101010101010101010101010101
legasy_session_id: legacy_session_id:
length: 00 length: 00
vector: -- vector: --
cipher_suites: cipher_suites:
length: 0002 length: 0002
vector: vector:
CipherSuite: C104 CipherSuite: C104
compression_methods: compression_methods:
length: 01 length: 01
vector: vector:
CompressionMethod: 00 CompressionMethod: 00
skipping to change at page 67, line 37 skipping to change at line 3199
---------------------------Server--------------------------- ---------------------------Server---------------------------
ServerHello message: ServerHello message:
msg_type: 02 msg_type: 02
length: 00007C length: 00007C
body: body:
legacy_version: 0303 legacy_version: 0303
random: 82828282828282828282828282828282 random: 82828282828282828282828282828282
82828282828282828282828282828282 82828282828282828282828282828282
legasy_session_id: legacy_session_id:
length: 00 length: 00
vector: -- vector: --
cipher_suite: cipher_suite:
CipherSuite: C104 CipherSuite: C104
compression_method: compression_method:
CompressionMethod: 00 CompressionMethod: 00
extensions: extensions:
length: 0054 length: 0054
vector: vector:
Extension: /* supported_versions */ Extension: /* supported_versions */
skipping to change at page 84, line 5 skipping to change at line 3962
Record layer message: Record layer message:
type: 17 type: 17
legacy_record_version: 0303 legacy_record_version: 0303
length: 000B length: 000B
encrypted_record: 464AEEAD391D97987169F3 encrypted_record: 464AEEAD391D97987169F3
TLSCiphertext: TLSCiphertext:
00000: 17 03 03 00 0B 46 4A EE AD 39 1D 97 98 71 69 F3 00000: 17 03 03 00 0B 46 4A EE AD 39 1D 97 98 71 69 F3
Appendix B. Contributors Contributors
* Lilia Akhmetzyanova
CryptoPro
lah@cryptopro.ru
* Alexandr Sokolov
CryptoPro
sokolov@cryptopro.ru
* Vasily Nikolaev Lilia Akhmetzyanova
CryptoPro
Email: lah@cryptopro.ru
CryptoPro Alexandr Sokolov
CryptoPro
Email: sokolov@cryptopro.ru
nikolaev@cryptopro.ru Vasily Nikolaev
CryptoPro
Email: nikolaev@cryptopro.ru
Authors' Addresses Authors' Addresses
Stanislav Smyshlyaev (editor) Stanislav Smyshlyaev (editor)
CryptoPro CryptoPro
18, Suschevsky val 18, Suschevsky val
Moscow Moscow
127018 127018
Russian Federation Russian Federation
Phone: +7 (495) 995-48-20 Phone: +7 (495) 995-48-20
skipping to change at page 84, line 50 skipping to change at line 4001
127018 127018
Russian Federation Russian Federation
Email: alekseev@cryptopro.ru Email: alekseev@cryptopro.ru
Ekaterina Griboedova Ekaterina Griboedova
CryptoPro CryptoPro
18, Suschevsky val 18, Suschevsky val
Moscow Moscow
127018 127018
Russian Federation Russian Federation
Email: griboedova.e.s@gmail.com Email: griboedovaekaterina@gmail.com
Alexandra Babueva Alexandra Babueva
CryptoPro CryptoPro
18, Suschevsky val 18, Suschevsky val
Moscow Moscow
127018 127018
Russian Federation Russian Federation
Email: babueva@cryptopro.ru Email: babueva@cryptopro.ru
Lidiia Nikiforova Lidiia Nikiforova
CryptoPro CryptoPro
 End of changes. 198 change blocks. 
516 lines changed or deleted 566 lines changed or added

This html diff was produced by rfcdiff 1.48.