GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
draft-smyshlyaev-tls13-gost-suites-00

Network Working Group                                 S. Smyshlyaev, Ed.
Internet-Draft                                               E. Alekseev
Intended status: Informational                            E. Smyshlyaeva
Expires: May 1, 2020                                          A. Babueva
                                                               CryptoPro
                                                        October 29, 2019

 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version
                                  1.3
                 draft-smyshlyaev-tls13-gost-suites-00

Abstract

   This document specifies a set of cipher suites for the Transport
   Layer Security (TLS) protocol Version 1.3 to support the Russian
   cryptographic standard algorithms.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 1, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Smyshlyaev, et al.         Expires May 1, 2020                  [Page 1]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  Basic Terms and Definitions . . . . . . . . . . . . . . . . .   3
   4.  Cipher Suite Definition . . . . . . . . . . . . . . . . . . .   5
     4.1.  Payload Protection  . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  AEAD Algorithm  . . . . . . . . . . . . . . . . . . .   6
         4.1.1.1.  Block Cipher  . . . . . . . . . . . . . . . . . .   7
         4.1.1.2.  TLSTREE . . . . . . . . . . . . . . . . . . . . .   8
         4.1.1.3.  SNMAX parameter . . . . . . . . . . . . . . . . .   9
     4.2.  HASH algorithm  . . . . . . . . . . . . . . . . . . . . .   9
   5.  Signature Scheme Definition . . . . . . . . . . . . . . . . .  10
   6.  Key Exchange and Authentication . . . . . . . . . . . . . . .  12
     6.1.  Key Exchange  . . . . . . . . . . . . . . . . . . . . . .  13
       6.1.1.  ECDHE Shared Secret Calculation . . . . . . . . . . .  13
         6.1.1.1.  ECDHE Parameters  . . . . . . . . . . . . . . . .  13
         6.1.1.2.  ECDHE Shared Secret Calculation on Client Side  .  14
         6.1.1.3.  ECDHE Shared Secret Calculation on Server Side  .  15
       6.1.2.  Values for the Supported Groups Registry  . . . . . .  16
     6.2.  Authentication  . . . . . . . . . . . . . . . . . . . . .  17
     6.3.  Handshake Messages  . . . . . . . . . . . . . . . . . . .  17
       6.3.1.  Hello Messages  . . . . . . . . . . . . . . . . . . .  18
       6.3.2.  CertificateRequest  . . . . . . . . . . . . . . . . .  18
       6.3.3.  CertificateVerify . . . . . . . . . . . . . . . . . .  19
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   8.  Historical considerations . . . . . . . . . . . . . . . . . .  21
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     10.2.  Informative References . . . . . . . . . . . . . . . . .  23
   Appendix A.  Test Examples  . . . . . . . . . . . . . . . . . . .  23
   Appendix B.  Contributors . . . . . . . . . . . . . . . . . . . .  23
   Appendix C.  Acknowledgments  . . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   This document specifies four new cipher suites for the Transport
   Layer Security (TLS) Protocol Version 1.3 [RFC8446] to support the
   set of Russian cryptographic standard algorithms called GOST
   algorithms (see Section 4).  These cipher suites use the hash
   algorithm GOST R 34.11-2012 [GOST3411-2012] (the English version can
   be found in [RFC6986]), the AEAD algorithm MGM [DraftMGM] and the
   block ciphers GOST R 34.12-2015 [GOST3412-2015] (the English version

Smyshlyaev, et al.         Expires May 1, 2020                  [Page 2]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   can be found in [RFC7801]).  The GOST cipher suites have the
   following values:

      TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {TBD1};
      TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {TBD2};
      TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {TBD3};
      TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {TBD4}.

   These cipher suites have different key lifetime value (see
   [RFC8645]), so they are divided into two types: the _S (strong)
   cipher suites and the _L (light) cipher suites (see Section 4.1.1.3,
   Section 4.1.1.2).

   This document specifies seven new signature schemes (see Section 5)
   to be used with GOST cipher suites.  These signature schemes use the
   signature algorithm GOST R 34.10-2012 [GOST3410-2012] (the English
   version can be found in [RFC7091]) and have the following values:

      gostr34102012_256a = {TBD5};

      gostr34102012_256b = {TBD6};

      gostr34102012_256c = {TBD7};

      gostr34102012_256d = {TBD8};

      gostr34102012_512a = {TBD9};

      gostr34102012_512b = {TBD10};

      gostr34102012_512c = {TBD11}.

   Additionally this document specifies the key exchange and
   authentication process in case of negotiating GOST cipher suites (see
   Section 6).

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Basic Terms and Definitions

   This document uses the following terms and definitions for the sets
   and operations on the elements of these sets:

Smyshlyaev, et al.         Expires May 1, 2020                  [Page 3]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

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

   B*      the set of all byte strings of a finite length (hereinafter
           referred to as strings), including the empty string;

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

   |A|     the byte length of the byte string A;

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

   i & j   bitwise AND of integers i and j;

   STR_t   the transformation that maps an integer i = 256^{t-1} * i_1 +
           ... + 256 * i_{t-1} + i_t into the byte string STR_t(i) =
           (i_1, ... , i_t) in B_t (the interpretation of the integer as
           a byte string in big-endian format);

   str_t   the transformation that maps an integer i = 256^{t-1} * i_t +
           ... + 256 * i_2 + i_1 into the byte string str_t(i) = (i_1,
           ... , i_t) in B_t (the interpretation of the integer as a
           byte string in little-endian format);

   k       the byte-length of the block cipher key;

   n       the byte-length of the block cipher block;

   E_i     elliptic curve indicated by client in "supported_group"
           extension;

   Q_c     the public key stored in the client's certificate;

   d_c     the private key that corresponds to the Q_c key;

   Q_s     the public key stored in the server's certificate;

   d_s     the private key that corresponds to the Q_s key;

   q_s     subgroup order of group of points of the elliptic curve that
           corresponds to Q_s;

   P_s     the point of order q_s that belongs to the same curve as Q_s;

Smyshlyaev, et al.         Expires May 1, 2020                  [Page 4]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

4.  Cipher Suite Definition

   This document defines the following new values for the "Cipher
   Suites" registry, that can be used in the ClientHello.cipher_suites
   and ServerHello.cipher_suites fields for the particular cipher suite:

   CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = TBD1;
   CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = TBD2;
   CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = TBD3;
   CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = TBD4;

   Each cipher suite defines the pair of the AEAD algorithm and the hash
   algorithm.  AEAD algorithm is used for the payload protection (see
   Section 4.1 for more details) and hash algorithm is used for key
   derivation and handshake message authentication.

4.1.  Payload Protection

   All of the cipher suites described in this document use the block
   cipher in Authenticated Encryption with Associated Data (AEAD) mode
   (see Section 4.1.1) to protect records.  The TLSCiphertext structure
   is specified in accordance with [RFC8446] as follows.

   struct {
       ContentType opaque_type = application_data; /* 23 */
       ProtocolVersion legacy_record_version = 0x0303; /*TLSv1.2*/
       uint16 length;
       opaque encrypted_record[TLSCiphertext.length];
   } TLSCiphertext;

   The encrypted_record field of TLSCiphertext is set to AEADEncrypted,
   where AEADEncrypted is computed as follows:

      AEADEncrypted = AEAD-Encrypt(sender_write_key, nonce,
      additional_data, plaintext),

   where

   o  AEAD-Encrypt function is defined in Section 4.1.1;

   o  the traffic key material that consists of the sender_write_key
      (either the client_write_key or the server_write_key) and the
      sender_write_IV (either the client_write_IV or the

Smyshlyaev, et al.         Expires May 1, 2020                  [Page 5]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

      server_write_IV) parameters is generated in accordance with
      Section 7.3 of [RFC8446];

   o  the nonce is derived from the sequence number and the
      sender_write_iv (see Section 5.3 of [RFC8446]);

   o  the plaintext input to the AEAD algorithm is the encoded
      TLSInnerPlaintext structure;

   o  the additional data input is the record header:

   additional_data = TLSCiphertext.opaque_type ||
                     TLSCiphertext.legacy_record_version ||
                     TLSCiphertext.length;

   In order to decrypt and verify, the cipher takes as input the key,
   nonce, additional data and the AEADEncrypted value.  The output is
   either the plaintext or an error indicating that the decryption
   failed.

      plaintext of encrypted_record = AEAD-Decrypt(sender_write_key,
      nonce, additional_data, AEADEncrypted)

   where AEAD-Decrypt function is defined in Section 4.1.1.

4.1.1.  AEAD Algorithm

   The GOST cipher suites use the block cipher in MGM authenticated
   encryption with associated data mode defined in [DraftMGM].  The base
   block cipher is defined in Section 4.1.1.1.  The size S of the
   authentication field is n bytes.  The IVlen parameter is n bytes.

   The record key material is a key material that is generated from the
   traffic key material and is used to protect a record with the certain
   sequence number.  All of the cipher suites described in this document
   use TLSTREE algorithm to derive record key material
   (Section 4.1.1.2).

   For each record with sequence number seqnum AEAD-Encrypt and AEAD-
   Decrypt functions are defined as follows.

Smyshlyaev, et al.         Expires May 1, 2020                  [Page 6]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   +-------------------------------------------------------------------+
   |  AEAD-Encrypt(K, nonce, A, P)                                     |
   |-------------------------------------------------------------------|
   |  Input:                                                           |
   |  - encryption key K in B_k,                                       |
   |  - unique vector nonce in B_IVlen,                                |
   |  - additional authenticated data A in B_s, s >= 0,                |
   |  - plaintext P in B_s, s >= 0.                                    |
   |  Output:                                                          |
   |  - ciphertext C in B_{|P|},                                       |
   |  - authentication tag T T in B_S.                                 |
   |-------------------------------------------------------------------|
   |  1. K^seqnum = TLSTREE(K, seqnum)                                 |
   |  2. MGMnonce = nonce[1..1] & 0x7f | nonce[2..IVlen]               |
   |  3. (MGMnonce, A, C, T) = MGM-Encrypt(K^seqnum, MGMnonce, A, P)   |
   |  4. Return C | T.                                                 |
   +-------------------------------------------------------------------+

   +-------------------------------------------------------------------+
   |  AEAD-Decrypt(K, nonce, A, C | T)                                 |
   |-------------------------------------------------------------------|
   |  Input:                                                           |
   |  - encryption key K in B_k,                                       |
   |  - unique vector nonce in B_IVlen,                                |
   |  - additional authenticated data A in B_s, s >= 0,                |
   |  - ciphertext C in B_s, s >= 0                                    |
   |  - authentication tag T in B_S.                                   |
   |  Output:                                                          |
   |  - plaintext P in B_{|C|} or FAIL.                                |
   |-------------------------------------------------------------------|
   |  1. K^seqnum = TLSTREE(K, seqnum)                                 |
   |  2. MGMnonce = nonce[1..1] & 0x7f | nonce[2..IVlen]               |
   |  3. res' = MGM-Decrypt(K^seqnum, MGMnonce, A, C, T)               |
   |  4. IF res' = FAIL then return FAIL; else return P.               |
   +-------------------------------------------------------------------+

   MGM-Encrypt and MGM-Decrypt functions are defined in [DraftMGM],
   TLSTREE function is defined in Section 4.1.1.2.  The maximum value of
   the sequence number seqnum during one TLS 1.3 connection is defined
   in Section 4.1.1.3.

4.1.1.1.  Block Cipher

   The cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and
   TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik
   [RFC7801] as a base block cipher for the AEAD algorithm.  The block
   length n is 16 bytes and the key length k is 32 bytes.

Smyshlyaev, et al.         Expires May 1, 2020                  [Page 7]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   The cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and
   TLS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST uses Magma [GOST3412-2015]
   as a base block cipher for the AEAD algorithm.  The block length n is
   8 bytes and the key length k is 32 bytes.

4.1.1.2.  TLSTREE

   The GOST cipher suites use the TLSTREE function for the external re-
   keying approach (see [RFC8645]).  The TLSTREE function is defined as
   follows:

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

   where

   o  K_root in B_32;

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

   o  KDF_j(K, D), j = 1, 2, 3, K in B_32, D in B_8, is the key
      derivation function based on the KDF_GOSTR3411_2012_256 function
      defined in [RFC7836]:

      KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D);
      KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D);
      KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D).

   o  C_1, C_2, C_3 are constants defined by the particular cipher
      suite:

Smyshlyaev, et al.         Expires May 1, 2020                  [Page 8]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   +------------------------------------------+----------------------+
   |               CipherSuites               |    C_1, C_2, C_3     |
   +------------------------------------------+----------------------+
   |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L |C_1=0xf800000000000000|
   |                                          |C_2=0xfffffff000000000|
   |                                          |C_3=0xffffffffffffe000|
   +------------------------------------------+----------------------+
   |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L      |C_1=0xffe0000000000000|
   |                                          |C_2=0xffffffffc0000000|
   |                                          |C_3=0xffffffffffffff80|
   +------------------------------------------+----------------------+
   |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S |C_1=0xffffffffe0000000|
   |                                          |C_2=0xffffffffffff0000|
   |                                          |C_3=0xfffffffffffffff8|
   +------------------------------------------+----------------------+
   |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S      |C_1=0xfffffffffc000000|
   |                                          |C_2=0xffffffffffffe000|
   |                                          |C_3=0xffffffffffffffff|
   +------------------------------------------+----------------------+
                              Table 1

4.1.1.3.  SNMAX parameter

   The SNMAX parameter defines the maximal value of the sequence number
   seqnum during one TLS 1.3 connection and is defined as follows:

   +------------------------------------------+--------------------+
   |               CipherSuites               |        SNMAX       |
   +------------------------------------------+--------------------+
   |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L | SNMAX = 2^64 - 1   |
   +------------------------------------------+--------------------+
   |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L      | SNMAX = 2^64 - 1   |
   +------------------------------------------+--------------------+
   |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S | SNMAX = 2^42 - 1   |
   +------------------------------------------+--------------------+
   |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S      | SNMAX = 2^39 - 1   |
   +------------------------------------------+--------------------+
                              Table 2

4.2.  HASH algorithm

   The function HASH for all the cipher suites defined in this document
   is the GOST R 34.11-2012 [RFC6986] hash algorithm with 32-byte
   (256-bit) hash code.

Smyshlyaev, et al.         Expires May 1, 2020                  [Page 9]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   The function HASH is used for key derivation process (see Section 7.1
   of [RFC8446]), Finished message calculation, Transcript-Hash
   function, PSK binder value calculation, derivation of record key
   material (see Section 4.1.1.2) and other purposes during key exchange
   process.

5.  Signature Scheme Definition

   The signature scheme values are used to indicate to the server/client
   which signature algorithms and curves can be used in digital
   signatures and are defined by the SignatureSchemeList structure (see
   Section 4.2.3 of [RFC8446]) as follows:

   struct {
       SignatureScheme supported_signature_algorithms<2..2^16-2>;
   } SignatureSchemeList;

   This document defines new values for the "SignatureAlgorithm"
   registry that can be used in the
   SignatureSchemeList.supported_signature_algorithms field for the
   particular signature scheme:

   enum {
       gostr34102012_256a(TBD5),
       gostr34102012_256b(TBD6),
       gostr34102012_256c(TBD7),
       gostr34102012_256d(TBD8),
       gostr34102012_512a(TBD9),
       gostr34102012_512b(TBD10),
       gostr34102012_512c(TBD11)
   } SignatureScheme;

   where the values correspond to the following signature algorithms and
   curves:

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 10]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   +------------------+--------------------------------------+--------+
   | SignatureScheme  |          Signature Algorithm         | Refe-  |
   |      Value       |                                      | rences |
   +------------------+--------------------------------------+--------+
   |gostr34102012_256a|GOST R 34.10-2012 + 32-byte key length|RFC 7091|
   +------------------+--------------------------------------+--------+
   |gostr34102012_256b|GOST R 34.10-2012 + 32-byte key length|RFC 7091|
   +------------------+--------------------------------------+--------+
   |gostr34102012_256c|GOST R 34.10-2012 + 32-byte key length|RFC 7091|
   +------------------+--------------------------------------+--------+
   |gostr34102012_256d|GOST R 34.10-2012 + 32-byte key length|RFC 7091|
   +------------------+--------------------------------------+--------+
   |gostr34102012_512a|GOST R 34.10-2012 + 64-byte key length|RFC 7091|
   +------------------+--------------------------------------+--------+
   |gostr34102012_512b|GOST R 34.10-2012 + 64-byte key length|RFC 7091|
   +------------------+--------------------------------------+--------+
   |gostr34102012_512c|GOST R 34.10-2012 + 64-byte key length|RFC 7091|
   +------------------+--------------------------------------+--------+
                                Table 3

   +------------------+--------------------------------------+--------+
   | SignatureScheme  |        Curve Identifier Value        | Refe-  |
   |      Value       |                                      | rences |
   +------------------+--------------------------------------+--------+
   |gostr34102012_256a| id-tc26-gost-3410-2012-256-paramSetA |RFC 7836|
   +------------------+--------------------------------------+--------+
   |gostr34102012_256b|id-GostR3410-2001-CryptoPro-A-ParamSet|RFC 4357|
   +------------------+--------------------------------------+--------+
   |gostr34102012_256c|id-GostR3410-2001-CryptoPro-B-ParamSet|RFC 4357|
   +------------------+--------------------------------------+--------+
   |gostr34102012_256d|id-GostR3410-2001-CryptoPro-C-ParamSet|RFC 4357|
   +------------------+--------------------------------------+--------+
   |gostr34102012_512a|  id-tc26-gost-3410-12-512-paramSetA  |RFC 7836|
   +------------------+--------------------------------------+--------+
   |gostr34102012_512b|  id-tc26-gost-3410-12-512-paramSetB  |RFC 7836|
   +------------------+--------------------------------------+--------+
   |gostr34102012_512c| id-tc26-gost-3410-2012-512-paramSetC |RFC 7836|
   +------------------+--------------------------------------+--------+
                                Table 4

   This document defines the SIGN function which is used for computing
   signature value in CertificateVerify message (see Section 6.3.3) as
   follows.

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 11]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   +-----------------------------------------------------+
   |  SIGN(M, d_sign)                                    |
   |-----------------------------------------------------|
   |  Input:                                             |
   |  - the byte string M in B*;                         |
   |  - the sign key d_sign: 0 <= d_sign <= q.           |
   |  Output:                                            |
   |  - signature value sgn in B_{2*l}.                  |
   |-----------------------------------------------------|
   |  1. (r, s) = SIGNGOST(M, d_sign)                    |
   |  2. Return str_l(r) | str_l(s)                      |
   |-----------------------------------------------------+

   where

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

   o  l is defined as follows:

      *  l = 32 for gostr34102012_256a, gostr34102012_256b,
         gostr34102012_256c and gostr34102012_256d values of the
         SignatureScheme field;

      *  l = 64 for gostr34102012_512a, gostr34102012_512b and
         gostr34102012_512c values of the SignatureScheme field;

   o  SIGNGOST(M, d_sign) is the GOST R 34.10-2012 [RFC7091] signature
      algorithm.

   The signature value sgn is the concatenation of two strings that are
   byte representations of r and s values in the little-endian format.

   According to [RFC7091] the GOST R 34.10-2012 signature algorithm with
   32-byte (256-bit) or 64-byte (512-bit) key length use the GOST R
   34.11-2012 [RFC6986] hash algorithm with 32-byte (256-bit) or 64-byte
   (512-bit) hash code respectively (the hash algorithm is intrinsic to
   the signature algorithm).

6.  Key Exchange and Authentication

   Key exchange and authentication process in case of using GOST cipher
   suites is defined in [RFC8446] and Section 6.1, Section 6.2.
   Additionally the proposed cipher suites specify some Handshake
   messages (see Section 6.3).

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 12]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

6.1.  Key Exchange

   TLS 1.3 supports three basic key exchange modes in accordance with
   [RFC8446]:

      1.  (EC)DHE

      2.  PSK-only

      3.  PSK with (EC)DHE

   All of the cipher suites described in this document use Diffie-
   Hellman over elliptic curves in (EC)DHE and PSK with (EC)DHE key
   exchange modes.  Diffie-Hellman over finite fields SHOULD NOT be
   used.  This document defines the process of ECDHE shared secret
   calculation (see Section 6.1.1) and specifies the elliptic curves
   that can be used during this process (see Section 6.1.2).

   In accordance with [RFC8446] PSKs can be divided into two types:

   o  internal PSKs which can be established during the previous
      connection;

   o  external PSKs which can be established out of band.

   This document defines that PSK-only key exchange mode SHOULD be used
   only with the internal PSKs.  External PSKs SHOULD be used together
   with certificates in PSK with (EC)DHE mode only.

6.1.1.  ECDHE Shared Secret Calculation

6.1.1.1.  ECDHE Parameters

   ECDHE parameters for both clients and servers are encoded in the
   opaque key_exchange field of a KeyShareEntry in a KeyShare structure.

   For GOST cipher suites the contents are the serialized value of the
   following struct:

   struct {
       opaque X[coordinate_length];
       opaque Y[coordinate_length];
   } PlainPointRepresentation;

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 13]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   X and Y, respectively, contain the binary representations of the x
   and y values of point Q (Q = (x, y)) in the little-endian format and
   are specified as follows:

      X = str_{coordinate_length}(x);

      Y = str_{coordinate_length}(y).

   The coordinate_length value is defined in Table 5.

6.1.1.2.  ECDHE Shared Secret Calculation on Client Side

   The client calculates ECDHE shared secret value in accordance with
   the following steps:

   1.  Chooses from all supported curves E_1, ..., E_R the set of curves
   E_{i_1}, ..., E_{i_r}, 1 <= i_1 <= i_r <= R, where

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

   o  r = 1 in the case of responding to HelloRetryRequest message,
      E_{i_1} SHOULD correspond to the curve indicated in the key_share
      extension in the HelloRetryRequest message.

   2.  Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ...,
   (d_C^{i_r}, Q_C^{i_r}) corresponding to E_{i_1}, ..., E_{i_r} curves,
   where for each i in {i_1, ..., i_r}:

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

   o  Q_C^i = d_C^i * P_i.

   3.  Sends ClientHello message specified in accordance with
   Section 4.1.2 of [RFC8446] and Section 6.3.1, which contains:

   o  key_share extension with public ephemeral keys Q_C^{i_1}, ...,
      Q_C^{i_r} specified in accordance with Section 4.2.8 of [RFC8446];

   o  supported_group extension with supported curves E_1, ..., E_R
      specified in accordance with Section 4.2.7 of [RFC8446].

   4.  In case of receiving HelloRetryRequest message client should
   return to step 1 and correct parameters according to Section 4.1.2 of
   [RFC8446].  In case of receiving ServerHello message client proceeds
   to the next step.  In other cases client MUST terminate the
   connection with "unexpected_message" alert.

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 14]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   5.  Extracts curve E_res and ephemeral key Q_S^res, res in {1, ...,
   R}, from ServerHello message and checks whether the Q_res belongs to
   E_res.  If this check fails, the client MUST abort the handshake with
   "handshake_failure" alert.

   6.  Generates Q^ECDHE:

      Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) * Q_S^res.

   7.  Client MUST check whether the computed shared secret Q^ECDHE is
   not equal to zero point.  If this check fails, the client MUST abort
   the handshake with "handshake_failure" alert.

   8.  Shared secret value ECDHE is the byte representation of the
   coordinate X^ECDHE of point Q^ECDHE in the little-endian format:

      ECDHE = str_{coordinate_length}(X^ECDHE),

   where coordinate_length is defined in Table 5.

6.1.1.3.  ECDHE Shared Secret Calculation on Server Side

   Upon receiving the ClientHello message, the server calculates ECDHE
   shared secret value in accordance with the following steps:

   1.  Chooses the curve E_res, res in {1, ..., R} from the list of
   curves E_1, ..., E_R indicated in supported_group extension in
   ClientHello message and the corresponding public ephemeral key value
   Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r}, 1 <= i_1 <= i_r <=
   R, indicated in key_share extension.  If no corresponding public
   ephemeral key value is found (res in {1, ..., R}\{i_1, ..., i_r}),
   server MAY send HelloRetryRequest message with key_share extension
   indicated E_res and wait for the next ClientHello message.

   2.  Checks whether Q_res belongs to E_res.  If this check fails, the
   server MUST abort the handshake with "handshake_failure" alert.

   3.  Generates ephemeral key pair (d_S^res, Q_S^res) corresponding to
   E_res:

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

   o  Q_S^res = d_S^res * P_res.

   4.  Sends ServerHello message specified in accordance with
   Section 4.1.3 of [RFC8446] and Section 6.3.1 with key_share extension
   indicated public ephemeral key value Q_S^res corresponding to E_res.

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 15]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   5.  Generates Q^ECDHE:

      Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res.

   6.  Server MUST check whether the computed shared secret Q^ECDHE is
   not equal to zero point.  If this check fails, the server MUST abort
   the handshake with "handshake_failure" alert.

   7.  Shared secret value ECDHE is the byte representation of the
   coordinate X^ECDHE of point Q^ECDHE in the little-endian format:

      ECDHE = str_{coordinate_length}(X^ECDHE),

   where coordinate_length is defined in Table 5.

6.1.2.  Values for the Supported Groups Registry

   The supported_groups extension indicates the set of elliptic curves
   supported by the client and is defined in [RFC8446].

   This document defines the following values for the "Supported Groups"
   registry:

   enum {
       GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25),
       GC512A(0x26), GC512B(0x27), GC512C(0x28)
   } NamedGroup;

   Where the values correspond to the following curves and the following
   values of coordinate_length parameter ("cl" column).

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 16]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   +-----------+--------------------------------------+----+---------+
   |Description|       Curve Identifier Value         | cl |Reference|
   +-----------+--------------------------------------+----+---------+
   |  GC256A   | id-tc26-gost-3410-2012-256-paramSetA | 32 | RFC 7836|
   +-----------+--------------------------------------+----+---------+
   |  GC256B   |id-GostR3410-2001-CryptoPro-A-ParamSet| 32 | RFC 4357|
   +-----------+--------------------------------------+----+---------+
   |  GC256C   |id-GostR3410-2001-CryptoPro-B-ParamSet| 32 | RFC 4357|
   +-----------+--------------------------------------+----+---------+
   |  GC256D   |id-GostR3410-2001-CryptoPro-C-ParamSet| 32 | RFC 4357|
   +-----------+--------------------------------------+----+---------+
   |  GC512A   |  id-tc26-gost-3410-12-512-paramSetA  | 64 | RFC 7836|
   +-----------+--------------------------------------+----+---------+
   |  GC512B   |  id-tc26-gost-3410-12-512-paramSetB  | 64 | RFC 7836|
   +-----------+--------------------------------------+----+---------+
   |  GC512C   | id-tc26-gost-3410-2012-512-paramSetC | 64 | RFC 7836|
   +-----------+--------------------------------------+----+---------+
                                Table 5

   These values are the same as in [DraftGostTLS12].

6.2.  Authentication

   In accordance with [RFC8446] authentication can happen via signature
   with certificate or via symmetric pre-shared key (PSK).  The server
   side of the channel is always authenticated; the client side is
   optionally authenticated.

   PSK-based authentication happens as a side effect of key exchange.
   This document defines that external PSKs SHOULD be combined only with
   the mutual autentication.

   Certificate-based authentication happens via authentication messages.
   This document defines the signature schemes that are used for
   certificate-based authentication (see Section 5) and specifies some
   autehtication messages (see Section 6.3.2, Section 6.3.3).

6.3.  Handshake Messages

   The proposed cipher suites specify the ClientHello, ServerHello,
   CertificateRequest and CertificateVerify handshake messages, that are
   described in further detail below.

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 17]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

6.3.1.  Hello Messages

   The ClientHello message is generated in accordance with the following
   requirements.

   o  The ClientHello.cipher_suites field SHOULD contain cipher suites
      with the values defined in Section 4.

   o  The ClientHello.extensions field MAY contain the
      signature_algorithms and signature_algorithms_cert extensions.
      The extension_data field of these extensions contains a
      SignatureSchemeList value, where
      SignatureSchemeList.supported_signature_algorithms field SHOULD
      contain only the values defined in Section 5.

   o  The ClientHello.extensions field MAY contain the supported_group
      extension.  The extension_data field of this extension contains a
      NamedGroupList value, where NamedGroupList.named_group_list field
      SHOULD contain only the values defined in Section 6.1.2.

   o  The ClientHello.extensions field SHOULD NOT contain early_data
      extension.

   The ServerHello message is generated in accordance with the following
   requirements.

   o  The ServerHello.cipher_suites field SHOULD contain cipher suites
      with the values defined in Section 4.

6.3.2.  CertificateRequest

   This message is sent when requesting client authentication and is
   specified in accordance with [RFC8446] as follows.

   struct {
       opaque certificate_request_context<0..2^8-1>;
       Extension extensions<2..2^16-1>;
   } CertificateRequest;

   If the GOST cipher suite is negotiated, the CertificateRequest
   message MUST meet the following requirements.

   o  The CertificateRequest.extensions field MUST contain the
      signature_algorithms extension.  The "extension_data" field of
      this extension contains a SignatureSchemeList value, where

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 18]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

      SignatureSchemeList.supported_signature_algorithms field SHOULD
      contain only the values defined in Section 5.

   o  The CertificateRequest.extensions field MAY contain the
      signature_algorithms_cert extension.  The "extension_data" field
      of this extension contains a SignatureSchemeList value, where
      SignatureSchemeList.supported_signature_algorithms field SHOULD
      contain only the values defined in Section 5.

6.3.3.  CertificateVerify

   This CertificateVerify message is used to provide explicit proof that
   an endpoint possesses the private key corresponding to its
   certificate and is specified in accordance with [RFC8446] as follows.

   struct {
       SignatureScheme algorithm;
       opaque signature<0..2^16-1>;
   } CertificateVerify;

   If the GOST cipher suite is negotiated, the CertificateVerify message
   MUST meet the following requirements.

   o  The CertificateVerify.algorithm field SHOULD contain only the
      signature schemes with the values defined in Section 5.

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

         sgn = SIGN(M, d_sign),

   o  where

      *  function SIGN is defined in Section 5,

      *  structure of M is defined in Section 4.4.3 of [RFC8446],

      *  d_sign is the sender long-term private key that corresponds to
         the sender long-term public key Q_sign from the sender's
         certificate.

7.  IANA Considerations

   IANA is asked to assign numbers TBD1, TBD2, TBD3 and TBD4 with the
   names TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L,
   TLS_GOSTR341112_256_WITH_MAGMA_MGM_L,

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 19]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S,
   TLS_GOSTR341112_256_WITH_MAGMA_MGM_S to the "TLS Cipher Suites"
   registry with this document as reference, as shown below.

   +-----+-----------------------------------------+-------+----------+
   |Value|              Description                |DTLS-OK| Reference|
   +-----+-----------------------------------------+-------+----------+
   |TBD1 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L|   ?   | this RFC |
   +-----+-----------------------------------------+-------+----------+
   |TBD2 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_L     |   ?   | this RFC |
   +-----+-----------------------------------------+-------+----------+
   |TBD3 |TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S|   ?   | this RFC |
   +-----+-----------------------------------------+-------+----------+
   |TBD4 |TLS_GOSTR341112_256_WITH_MAGMA_MGM_S     |   ?   | this RFC |
   +-----+-----------------------------------------+-------+----------+
                             Table 6

   IANA is asked to assign numbers TBD5, TBD6, TBD7, TBD8, TBD9, TBD10
   and TBD11 with the names gostr34102012_256a, gostr34102012_256b,
   gostr34102012_256c, gostr34102012_256d, gostr34102012_512a,
   gostr34102012_512b, gostr34102012_512c to the "TLS
   SignatureAlgorithm" registry, as shown below.

   +-----------+----------------------+---------+----------+
   |   Value   |      Description     | DTLS-OK | Reference|
   +-----------+----------------------+---------+----------+
   |   TBD5    |  gostr34102012_256a  |    ?    | this RFC |
   +-----------+----------------------+---------+----------+
   |   TBD6    |  gostr34102012_256b  |    ?    | this RFC |
   +-----------+----------------------+---------+----------+
   |   TBD7    |  gostr34102012_256c  |    ?    | this RFC |
   +-----------+----------------------+---------+----------+
   |   TBD8    |  gostr34102012_256d  |    ?    | this RFC |
   +-----------+----------------------+---------+----------+
   |   TBD9    |  gostr34102012_512a  |    ?    | this RFC |
   +-----------+----------------------+---------+----------+
   |   TBD10   |  gostr34102012_512b  |    ?    | this RFC |
   +-----------+----------------------+---------+----------+
   |   TBD11   |  gostr34102012_512c  |    ?    | this RFC |
   +-----------+----------------------+---------+----------+
                            Table 7

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 20]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

8.  Historical considerations

   Due to historical reasons in addition to the curve identifier values
   listed in Table 5 there exist some extra identifier values that
   correspond to the signature schemes as follows.

   +--------------------+-------------------------------------------+
   |     Description    |          Curve Identifier Value           |
   +--------------------+-------------------------------------------+
   | gostr34102012_256b | id-GostR3410_2001-CryptoPro-XchA-ParamSet |
   |                    | id-tc26-gost-3410-2012-256-paramSetB      |
   +--------------------+-------------------------------------------+
   | gostr34102012_256c | id-tc26-gost-3410-2012-256-paramSetC      |
   +--------------------+-------------------------------------------+
   | gostr34102012_256d | id-GostR3410-2001-CryptoPro-XchB-ParamSet |
   |                    | id-tc26-gost-3410-2012-256-paramSetD      |
   +--------------------+-------------------------------------------+
                            Table 8

   Client should be prepared to handle any of them correctly if
   corresponding signature scheme is included in the
   signature_algorithms or signature_algorithms_cert extensions.

9.  Security Considerations

   In order to create an effective implementation and to resist attacks
   client and server SHOULD stick to the following rules.

   1.  While using TLSTREE algorithm function KDF_j, j = 1, 2, 3, SHOULD
   be invoked only if sequence number seqnum reaches such value that

      seqnum & C_j != (seqnum - 1) & C_j.

   Otherwise the previous value should be used.

   2.  For each pre-shared key value PSK the binder_key value should be
   computed only once within all connections where ClientHello message
   contains a pre_shared_key extension indicating this PSK value.

   3.  Server SHOULD NOT send Application Data prior to receiving first
   client's Finished message in a mutually authenticated connection.

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 21]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

10.  References

10.1.  Normative References

   [DraftGostTLS12]
              Smyshlyaev, S., Belyavsky, D., and M. Saarinen, "GOST
              Cipher Suites for Transport Layer Security (TLS) Protocol
              Version 1.2", 2019, <https://tools.ietf.org/html/draft-
              smyshlyaev-tls12-gost-suites-05>.

   [DraftMGM]
              Smyshlyaev, S., Nozdrunov, V., Shishkin, V., and E.
              Smyshlyaeva, "Multilinear Galois Mode (MGM)", 2018,
              <https://tools.ietf.org/html/draft-smyshlyaev-mgm-09>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6986]  Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:
              Hash Function", RFC 6986, DOI 10.17487/RFC6986, August
              2013, <https://www.rfc-editor.org/info/rfc6986>.

   [RFC7091]  Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012:
              Digital Signature Algorithm", RFC 7091,
              DOI 10.17487/RFC7091, December 2013,
              <https://www.rfc-editor.org/info/rfc7091>.

   [RFC7801]  Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher
              "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016,
              <https://www.rfc-editor.org/info/rfc7801>.

   [RFC7836]  Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V.,
              Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines
              on the Cryptographic Algorithms to Accompany the Usage of
              Standards GOST R 34.10-2012 and GOST R 34.11-2012",
              RFC 7836, DOI 10.17487/RFC7836, March 2016,
              <https://www.rfc-editor.org/info/rfc7836>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8645]  Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric
              Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019,
              <https://www.rfc-editor.org/info/rfc8645>.

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 22]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

10.2.  Informative References

   [GOST3410-2012]
              Federal Agency on Technical Regulating and Metrology,
              "Information technology. Cryptographic data security.
              Signature and verification processes of [electronic]
              digital signature", GOST R 34.10-2012, 2012.

   [GOST3411-2012]
              Federal Agency on Technical Regulating and Metrology,
              "Information technology. Cryptographic Data Security.
              Hashing function", GOST R 34.11-2012, 2012.

   [GOST3412-2015]
              Federal Agency on Technical Regulating and Metrology,
              "Information technology. Cryptographic data security.
              Block ciphers", GOST R 34.12-2015, 2015.

Appendix A.  Test Examples

   TODO

Appendix B.  Contributors

   o  Lilia Akhmetzyanova
      CryptoPro
      lah@cryptopro.ru

   o  Alexandr Sokolov
      CryptoPro
      sokolov@cryptopro.ru

   o  Vasily Nikolaev
      CryptoPro
      nikolaev@cryptopro.ru

Appendix C.  Acknowledgments

Authors' Addresses

   Stanislav Smyshlyaev (editor)
   CryptoPro
   18, Suschevsky val
   Moscow  127018
   Russian Federation

   Phone: +7 (495) 995-48-20
   Email: svs@cryptopro.ru

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 23]
Internet-Draft       GOST Cipher Suites for TLS 1.3         October 2019

   Evgeny Alekseev
   CryptoPro
   18, Suschevsky val
   Moscow  127018
   Russian Federation

   Email: alekseev@cryptopro.ru

   Ekaterina Smyshlyaeva
   CryptoPro
   18, Suschevsky val
   Moscow  127018
   Russian Federation

   Email: ess@cryptopro.ru

   Alexandra Babueva
   CryptoPro
   18, Suschevsky val
   Moscow  127018
   Russian Federation

   Email: babueva@cryptopro.ru

Smyshlyaev, et al.         Expires May 1, 2020                 [Page 24]