rfc9189xml2.original.xml   rfc9189.xml 
<?xml version = "1.0" encoding = "utf-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" docN
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> ame="draft-smyshlyaev-tls12-gost-suites-18" indexInclude="true" ipr="trust200902
<?rfc toc="yes"?> " number="9189" prepTime="2022-02-28T11:38:28" scripts="Common,Latin" sortRefs="
<?rfc tocdepth="4"?> true" submissionType="independent" symRefs="true" tocDepth="4" tocInclude="true"
<?rfc symrefs="yes"?> xml:lang="en">
<?rfc sortrefs="yes" ?> <link href="https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suite
<?rfc compact="no" ?> s-18" rel="prev"/>
<link href="https://dx.doi.org/10.17487/rfc9189" rel="alternate"/>
<rfc category="info" docName="draft-smyshlyaev-tls12-gost-suites-18" ipr="trust2 <link href="urn:issn:2070-1721" rel="alternate"/>
00902"> <front>
<title abbrev="GOST Cipher Suites for TLS 1.2">GOST Cipher Suites for Transp
<front> ort Layer Security (TLS) Protocol Version 1.2</title>
<title abbrev="GOST Cipher Suites for TLS 1.2"> <seriesInfo name="RFC" value="9189" stream="independent"/>
GOST Cipher Suites for Transport Layer Security (TLS) Protocol Versi <author fullname="Stanislav Smyshlyaev" initials="S." role="editor" surname=
on 1.2 "Smyshlyaev">
</title> <organization showOnFrontPage="true">CryptoPro</organization>
<address>
<author fullname="Stanislav Smyshlyaev" initials="S.V." role="editor" su <postal>
rname="Smyshlyaev"> <street>18, Suschevsky val</street>
<organization>CryptoPro</organization> <city>Moscow</city>
<address> <code>127018</code>
<postal> <country>Russian Federation</country>
<street>18, Suschevsky val </street> </postal>
<city>Moscow</city> <phone>+7 (495) 995-48-20</phone>
<code>127018</code> <email>svs@cryptopro.ru</email>
<country>Russian Federation</country> </address>
</postal> </author>
<phone>+7 (495) 995-48-20</phone> <author fullname="Dmitry Belyavskiy" initials="D." surname="Belyavskiy">
<email>svs@cryptopro.ru</email> <organization showOnFrontPage="true">Cryptocom</organization>
</address> <address>
</author> <postal>
<street>14/2, Kedrova St.</street>
<author fullname="Dmitry Belyavskiy" initials="D." surname="Belyavskiy"> <city>Moscow</city>
<organization>Cryptocom</organization> <code>117218</code>
<address> <country>Russian Federation</country>
<postal> </postal>
<street>14/2 Kedrova st</street> <email>beldmit@gmail.com</email>
<!-- Reorder these if your country does things differently - </address>
-> </author>
<city>Moscow</city> <author fullname="Evgeny Alekseev" initials="E." surname="Alekseev">
<code>117218</code> <organization showOnFrontPage="true">CryptoPro</organization>
<country>Russian Federation</country> <address>
</postal> <postal>
<email>beldmit@gmail.com</email> <street>18, Suschevsky val</street>
</address> <city>Moscow</city>
</author> <code>127018</code>
<country>Russian Federation</country>
<author fullname="Markku-Juhani O. Saarinen" initials="M-J." surname="Sa </postal>
arinen"> <email>alekseev@cryptopro.ru</email>
<organization>Independent Consultant</organization> </address>
<address> </author>
<email>mjos@iki.fi</email> <date month="02" year="2022"/>
</address> <area>General</area>
</author> <workgroup>Network Working Group</workgroup>
<keyword>GOST</keyword>
<author fullname="Evgeny Alekseev" initials="E.K." surname="Alekseev"> <keyword>cipher suite</keyword>
<organization>CryptoPro</organization> <keyword>TLS</keyword>
<address> <abstract pn="section-abstract">
<postal> <t indent="0" pn="section-abstract-1">
<street>18, Suschevsky val </street> This document specifies three new cipher suites, two new signature alg
<city>Moscow</city> orithms, seven new supported groups, and two new certificate types for the Trans
<code>127018</code> port
<country>Russian Federation</country> Layer Security (TLS) protocol version 1.2 to support the Russian crypt
</postal> ographic standard algorithms (called "GOST" algorithms).
<email>alekseev@cryptopro.ru</email> This document specifies a profile of TLS 1.2 with GOST algorithms so t
</address> hat implementers can produce interoperable implementations.
</author> </t>
<t indent="0" pn="section-abstract-2">
<date year="2021" /> This specification facilitates implementations
<!--если не указываем число и месяц, они подставляются автоматически--> that aim to support the GOST algorithms. This document does not imply
<area>General</area> IETF endorsement of the cipher suites, signature algorithms, supported
<!--как в rfc7748--> groups, and certificate types.
<workgroup>Network Working Group</workgroup> </t>
<keyword>GOST, cipher suite, TLS</keyword> </abstract>
<boilerplate>
<abstract> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t> "exclude" pn="section-boilerplate.1">
This document specifies three new cipher suites, two new signatu <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
re algorithms, seven new supported groups and two new certificate types for the >
Transport <t indent="0" pn="section-boilerplate.1-1">
Layer Security (TLS) protocol Version 1.2 to support the Russian This document is not an Internet Standards Track specification; it i
cryptographic standard algorithms (called GOST algorithms). s
This document specifies a profile of TLS 1.2 with GOST algorithm published for informational purposes.
s so that implementers can produce interoperable implementations. </t>
</t> <t indent="0" pn="section-boilerplate.1-2">
<t> This is a contribution to the RFC Series, independently of any
This specification is developed to facilitate implementations other RFC stream. The RFC Editor has chosen to publish this
that wish to support the GOST algorithms. This document does not document at its discretion and makes no statement about its value
imply for implementation or deployment. Documents approved for
IETF endorsement of the cipher suites, signature algorithms, sup publication by the RFC Editor are not candidates for any level of
ported groups and certificate types. Internet Standard; see Section 2 of RFC 7841.
</t> </t>
</abstract> <t indent="0" pn="section-boilerplate.1-3">
</front> Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<middle> <eref target="https://www.rfc-editor.org/info/rfc9189" brackets="non
<section title="Introduction" anchor="Introduction"> e"/>.
<t> </t>
This document specifies three new cipher suites, two new signatu </section>
re algorithms, seven new supported groups and two new certificate types for the <section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
Transport Layer Security (TLS) ude" pn="section-boilerplate.2">
Protocol Version 1.2 <xref target="RFC5246"/> to support the set <name slugifiedName="name-copyright-notice">Copyright Notice</name>
of Russian cryptographic standard algorithms (called GOST algorithms). This doc <t indent="0" pn="section-boilerplate.2-1">
ument specifies a profile of TLS 1.2 with GOST algorithms so that implementers c Copyright (c) 2022 IETF Trust and the persons identified as the
an produce interoperable implementations. document authors. All rights reserved.
The profile of TLS 1.2 with GOST algorithms uses the hash algori </t>
thm GOST R 34.11-2012 <xref target="RFC6986"/> <t indent="0" pn="section-boilerplate.2-2">
and the signature algorithm GOST R 34.10-2012 <xref target="RFC7 This document is subject to BCP 78 and the IETF Trust's Legal
091"/> Provisions Relating to IETF Documents
and use two types of cipher suites: the CTR_OMAC cipher suites a (<eref target="https://trustee.ietf.org/license-info" brackets="none
nd the CNT_IMIT cipher suite. "/>) in effect on the date of
</t> publication of this document. Please review these documents
<t> carefully, as they describe your rights and restrictions with
The CTR_OMAC cipher suites use the GOST R 34.12-2015 (see <xref respect to this document.
target="RFC7801"/>, <xref target="RFC8891"/>) block ciphers. </t>
</t> </section>
<t> </boilerplate>
The CNT_IMIT cipher suite uses the GOST 28147-89 <xref target="R <toc>
FC5830"/> block cipher. <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
</t> n="section-toc.1">
<t> <name slugifiedName="name-table-of-contents">Table of Contents</name>
This document specifies the profile of the TLS protocol version <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
1.2 with GOST algorithms. The profile of the TLS protocol version 1.3 <xref targ c.1-1">
et="RFC8446"/> with GOST algorithms is specified in a separate document <xref ta <li pn="section-toc.1-1.1">
rget="DraftGostTLS13"/>. <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
</t> ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
<t> derivedContent="" format="title" sectionFormat="of" target="name-introduction">
This specification is developed to facilitate implementations th Introduction</xref></t>
at wish to support the GOST algorithms. This document does not imply IETF endors </li>
ement of the cipher suites, signature algorithms, supported groups and certifica <li pn="section-toc.1-1.2">
te types. <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
</t> ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
</section> derivedContent="" format="title" sectionFormat="of" target="name-conventions-us
ed-in-this-do">Conventions Used in This Document</xref></t>
<section title="Conventions Used in This Document"> </li>
<t> <li pn="section-toc.1-1.3">
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
T", "SHOULD", "SHOULD NOT", ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this derivedContent="" format="title" sectionFormat="of" target="name-basic-terms-an
document are to be interpreted d-definitions">Basic Terms and Definitions</xref></t>
as described in BCP 14 <xref target="RFC2119"/> <xref target="RF </li>
C8174"/> when, and only when, <li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-cipher-suite-definitions">Cipher S
uite Definitions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-record-payload-protect
ion">Record Payload Protection</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.1.2">
<li pn="section-toc.1-1.4.2.1.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derived
Content="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-ctr_omac">
CTR_OMAC</xref></t>
</li>
<li pn="section-toc.1-1.4.2.1.2.2">
<t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derived
Content="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-cnt_imit">
CNT_IMIT</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-key-exchange-and-authe
ntica">Key Exchange and Authentication</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.2.2">
<li pn="section-toc.1-1.4.2.2.2.1">
<t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derived
Content="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-hello-mess
ages">Hello Messages</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derived
Content="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-server-cer
tificate">Server Certificate</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.3">
<t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derived
Content="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-certificat
erequest">CertificateRequest</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.4">
<t indent="0" pn="section-toc.1-1.4.2.2.2.4.1"><xref derived
Content="4.2.4" format="counter" sectionFormat="of" target="section-4.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-clientkeye
xchange">ClientKeyExchange</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.4.2.2.2.4.2">
<li pn="section-toc.1-1.4.2.2.2.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.2.2.4.2.1.1"><xref
derivedContent="4.2.4.1" format="counter" sectionFormat="of" target="section-4.
2.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-ctr_omac-2">CTR_OMAC</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.2.4.2.2.1"><xref
derivedContent="4.2.4.2" format="counter" sectionFormat="of" target="section-4.
2.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-cnt_imit-2">CNT_IMIT</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.2.2.5">
<t indent="0" pn="section-toc.1-1.4.2.2.2.5.1"><xref derived
Content="4.2.5" format="counter" sectionFormat="of" target="section-4.2.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-certificat
everify">CertificateVerify</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.6">
<t indent="0" pn="section-toc.1-1.4.2.2.2.6.1"><xref derived
Content="4.2.6" format="counter" sectionFormat="of" target="section-4.2.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-finished">
Finished</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-cryptographic-algorith
ms">Cryptographic Algorithms</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.3.2">
<li pn="section-toc.1-1.4.2.3.2.1">
<t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derived
Content="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-block-ciph
er">Block Cipher</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3.2.2">
<t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derived
Content="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-mac-algori
thm">MAC Algorithm</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.2.3.1"><xref derived
Content="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-encryption
-algorithm">Encryption Algorithm</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3.2.4">
<t indent="0" pn="section-toc.1-1.4.2.3.2.4.1"><xref derived
Content="4.3.4" format="counter" sectionFormat="of" target="section-4.3.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-prf-and-ha
sh-algorithms">PRF and HASH Algorithms</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3.2.5">
<t indent="0" pn="section-toc.1-1.4.2.3.2.5.1"><xref derived
Content="4.3.5" format="counter" sectionFormat="of" target="section-4.3.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-snmax-para
meter">SNMAX Parameter</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-new-values-for-the-tls-sign">New V
alues for the TLS SignatureAlgorithm Registry</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-new-values-for-the-tls-supp">New V
alues for the TLS Supported Groups Registry</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-new-values-for-the-tls-clie">New V
alues for the TLS ClientCertificateType Identifiers Registry</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-additional-algorithms">Additional
Algorithms</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-tlstree">TLSTREE</xref
></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.1.2">
<li pn="section-toc.1-1.8.2.1.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.2.1.1"><xref derived
Content="8.1.1" format="counter" sectionFormat="of" target="section-8.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-key-tree-p
arameters">Key Tree Parameters</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-key-export-and-key-imp
ort-a">Key Export and Key Import Algorithms</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.2.2">
<li pn="section-toc.1-1.8.2.2.2.1">
<t indent="0" pn="section-toc.1-1.8.2.2.2.1.1"><xref derived
Content="8.2.1" format="counter" sectionFormat="of" target="section-8.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-kexp15-and
-kimp15-algorithm">KExp15 and KImp15 Algorithms</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.2.2.1"><xref derived
Content="8.2.2" format="counter" sectionFormat="of" target="section-8.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-kexp28147-
and-kimp28147-alg">KExp28147 and KImp28147 Algorithms</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
"8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-key-exchange-generatio
n-alg">Key Exchange Generation Algorithms</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.3.2">
<li pn="section-toc.1-1.8.2.3.2.1">
<t indent="0" pn="section-toc.1-1.8.2.3.2.1.1"><xref derived
Content="8.3.1" format="counter" sectionFormat="of" target="section-8.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-keg-algori
thm">KEG Algorithm</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3.2.2">
<t indent="0" pn="section-toc.1-1.8.2.3.2.2.1"><xref derived
Content="8.3.2" format="counter" sectionFormat="of" target="section-8.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-keg_28147-
algorithm">KEG_28147 Algorithm</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8.2.4">
<t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent=
"8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-gostimit28147">gostIMI
T28147</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-historical-considerations">Histo
rical Considerations</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-test-examples">
Test Examples</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.13.2">
<li pn="section-toc.1-1.13.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent
="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-test-example
s-for-ctr_omac-">Test Examples for CTR_OMAC Cipher Suites</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.13.2.1.2">
<li pn="section-toc.1-1.13.2.1.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.2.1.1"><xref derive
dContent="A.1.1" format="counter" sectionFormat="of" target="section-appendix.a.
1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
tlstree-examples">TLSTREE Examples</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.13.2.1.2.1.2">
<li pn="section-toc.1-1.13.2.1.2.1.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.2.1.2.1.1"><xre
f derivedContent="A.1.1.1" format="counter" sectionFormat="of" target="section-a
ppendix.a.1.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" t
arget="name-tls_gostr341112_256_with_ma">TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC
Cipher Suite</xref></t>
</li>
<li pn="section-toc.1-1.13.2.1.2.1.2.2">
<t indent="0" pn="section-toc.1-1.13.2.1.2.1.2.2.1"><xre
f derivedContent="A.1.1.2" format="counter" sectionFormat="of" target="section-a
ppendix.a.1.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" t
arget="name-tls_gostr341112_256_with_ku">TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR
_OMAC Cipher Suite</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13.2.1.2.2">
<t indent="0" pn="section-toc.1-1.13.2.1.2.2.1"><xref derive
dContent="A.1.2" format="counter" sectionFormat="of" target="section-appendix.a.
1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
record-examples">Record Examples</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.13.2.1.2.2.2">
<li pn="section-toc.1-1.13.2.1.2.2.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.2.2.2.1.1"><xre
f derivedContent="A.1.2.1" format="counter" sectionFormat="of" target="section-a
ppendix.a.1.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" t
arget="name-tls_gostr341112_256_with_mag">TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMA
C Cipher Suite</xref></t>
</li>
<li pn="section-toc.1-1.13.2.1.2.2.2.2">
<t indent="0" pn="section-toc.1-1.13.2.1.2.2.2.2.1"><xre
f derivedContent="A.1.2.2" format="counter" sectionFormat="of" target="section-a
ppendix.a.1.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" t
arget="name-tls_gostr341112_256_with_kuz">TLS_GOSTR341112_256_WITH_KUZNYECHIK_CT
R_OMAC Cipher Suite</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13.2.1.2.3">
<t indent="0" pn="section-toc.1-1.13.2.1.2.3.1"><xref derive
dContent="A.1.3" format="counter" sectionFormat="of" target="section-appendix.a.
1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
handshake-examples">Handshake Examples</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.13.2.1.2.3.2">
<li pn="section-toc.1-1.13.2.1.2.3.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.2.3.2.1.1"><xre
f derivedContent="A.1.3.1" format="counter" sectionFormat="of" target="section-a
ppendix.a.1.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" t
arget="name-tls_gostr341112_256_with_magm">TLS_GOSTR341112_256_WITH_MAGMA_CTR_OM
AC Cipher Suite</xref></t>
</li>
<li pn="section-toc.1-1.13.2.1.2.3.2.2">
<t indent="0" pn="section-toc.1-1.13.2.1.2.3.2.2.1"><xre
f derivedContent="A.1.3.2" format="counter" sectionFormat="of" target="section-a
ppendix.a.1.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" t
arget="name-tls_gostr341112_256_with_kuzn">TLS_GOSTR341112_256_WITH_KUZNYECHIK_C
TR_OMAC Cipher Suite</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13.2.2">
<t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent
="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-test-example
s-for-cnt_imit-">Test Examples for CNT_IMIT Cipher Suites</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.13.2.2.2">
<li pn="section-toc.1-1.13.2.2.2.1">
<t indent="0" pn="section-toc.1-1.13.2.2.2.1.1"><xref derive
dContent="A.2.1" format="counter" sectionFormat="of" target="section-appendix.a.
2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
record-examples-2">Record Examples</xref></t>
</li>
<li pn="section-toc.1-1.13.2.2.2.2">
<t indent="0" pn="section-toc.1-1.13.2.2.2.2.1"><xref derive
dContent="A.2.2" format="counter" sectionFormat="of" target="section-appendix.a.
2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
handshake-examples-2">Handshake Examples</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
f></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="Introduction" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">
This document specifies three new cipher suites, two new signatu
re algorithms, seven new supported groups, and two new certificate types for the
Transport Layer Security (TLS)
protocol version 1.2 <xref target="RFC5246" format="default" sec
tionFormat="of" derivedContent="RFC5246"/> (note that <xref target="RFC5246" for
mat="default" sectionFormat="of" derivedContent="RFC5246"/> has been obsoleted b
y <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC
8446"/> ) to support the set of Russian cryptographic standard algorithms (calle
d "GOST" algorithms). This document specifies a profile of TLS 1.2 with GOST alg
orithms so that implementers can produce interoperable implementations.
The profile of TLS 1.2 with GOST algorithms uses the hash algori
thm GOST R 34.11-2012 <xref target="RFC6986" format="default" sectionFormat="of"
derivedContent="RFC6986"/>, the signature algorithm GOST R 34.10-2012 <xref tar
get="RFC7091" format="default" sectionFormat="of" derivedContent="RFC7091"/>,
and two types of cipher suites: the CTR_OMAC and the CNT_
IMIT.
</t>
<t indent="0" pn="section-1-2">
The CTR_OMAC cipher suites use the GOST R 34.12-2015 (see <xref
target="RFC7801" format="default" sectionFormat="of" derivedContent="RFC7801"/>
and <xref target="RFC8891" format="default" sectionFormat="of" derivedContent="R
FC8891"/>) block ciphers.
</t>
<t indent="0" pn="section-1-3">
The CNT_IMIT cipher suite uses the GOST 28147-89 <xref target="R
FC5830" format="default" sectionFormat="of" derivedContent="RFC5830"/> block cip
her.
</t>
<t indent="0" pn="section-1-4">
This document specifies the profile of the TLS protocol version
1.2 with GOST algorithms. The profile of the TLS protocol version 1.3 <xref targ
et="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> with
GOST algorithms is specified in a separate document <xref target="I-D.smyshlyae
v-tls13-gost-suites" format="default" sectionFormat="of" derivedContent="DraftGo
stTLS13"/>.
</t>
<t indent="0" pn="section-1-5">
This specification facilitates implementations that aim to support the
GOST algorithms. This document does not imply IETF endorsement of the cipher su
ites, signature algorithms, supported groups, and certificate types.
</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<name slugifiedName="name-conventions-used-in-this-do">Conventions Used in
This Document</name>
<t indent="0" pn="section-2-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "
<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted
as described in BCP 14 <xref target="RFC2119" format="default" s
ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa
ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when,
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
</t> </t>
</section> </section>
<section anchor="Definition" numbered="true" toc="include" removeInRFC="fals
<section title="Basic Terms and Definitions" anchor="Definition"> e" pn="section-3">
<t> This document uses the following terms and definitions for the se <name slugifiedName="name-basic-terms-and-definitions">Basic Terms and Def
ts and operations initions</name>
<t indent="0" pn="section-3-1">
This document follows the terminology from <xref target="I-D.ietf-tls-
rfc8446bis" format="default" sectionFormat="of" derivedContent="RFC8446bis"/> fo
r "preliminary secret" and "extended_main_secret".
</t>
<t indent="0" pn="section-3-2"> This document uses the following terms and
definitions for the sets and operations
on the elements of these sets: on the elements of these sets:
<list style = "hanging" hangIndent = "8"> </t>
<t hangText = "B_t"> <dl newline="false" spacing="normal" indent="10" pn="section-3-3">
the set of byte strings of length t, t >= 0, for t = 0 t <dt pn="section-3-3.1">B_t</dt>
he <dd pn="section-3-3.2">
the set of byte strings of length t, t &gt;= 0. For t =
0, the
B_t set consists of a single empty string of zero length . 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, 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, ... , 2 ... , a_t), where a_1, a_2, ... , a_t are in {0, ... , 2
55}; 55}.
</t> </dd>
<t hangText = "B*"> <dt pn="section-3-3.3">B*</dt>
<dd pn="section-3-3.4">
the set of all byte strings of a finite length the set of all byte strings of a finite length
(hereinafter referred to as strings), including the empt (hereinafter referred to as "strings"), including the em
y pty
string; string.
</t> </dd>
<t hangText = "A[i..j]"> <dt pn="section-3-3.5">A[i..j]</dt>
the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in B_{j-i <dd pn="section-3-3.6">
+1} where A = (a_1, ... , a_t) in B_t and 1&lt;=i&lt;=j&lt;=t; the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in B_{j-i
</t> +1}, where A = (a_1, ... , a_t) in B_t and 1&lt;=i&lt;=j&lt;=t.
<t hangText ="L(A)"> </dd>
the length of the byte string A in bytes; <dt pn="section-3-3.7">L(A)</dt>
</t> <dd pn="section-3-3.8">
<t hangText = "A | C"> the length of the byte string A in bytes.
</dd>
<dt pn="section-3-3.9">A | C</dt>
<dd pn="section-3-3.10">
concatenation of strings A and C both belonging to B*, i .e., concatenation of strings A and C both belonging to B*, i .e.,
a string in B_{L(A)+L(C)}, where the left substring in a string in B_{L(A)+L(C)}, where the left substring in
B_L(A) is equal to A, and the right substring in B_L(C) B_L(A) is equal to A and the right substring in B_L(C) i
is s
equal to C; equal to C.
</t> </dd>
<t hangText = "A XOR C"> <dt pn="section-3-3.11">A XOR C</dt>
bitwise exclusive-or of byte strings A and C both belong <dd pn="section-3-3.12">
ing to B_t (i.e. both are of length t bytes), i.e., bitwise exclusive-or of byte strings A and C both belong
a string in B_t such that if A = (a_1, a_2, ... , a_t), ing to B_t (both are of length t bytes), i.e.,
C = (c_1, c_2, ... , c_t) then a string in B_t such that if A = (a_1, a_2, ... , a_t) a
A XOR C = (a_1 (xor) c_1, a_2 (xor) c_2, ... , a_t (xor) nd C = (c_1, c_2, ... , c_t), then
c_t) where (xor) is bitwise exclusive-or of bytes; A XOR C = (a_1 (xor) c_1, a_2 (xor) c_2, ... , a_t (xor)
</t> c_t), where (xor) is bitwise exclusive-or of bytes.
<t hangText = "i &amp; j"> </dd>
bitwise AND of unsigned integers i and j; <dt pn="section-3-3.13">i &amp; j</dt>
</t> <dd pn="section-3-3.14">
<t hangText = "STR_t"> bitwise AND of unsigned integers i and j.
the transformation that maps an integer i = 256^{t-1} * </dd>
i_1 + ... + 256 * i_{t-1} + i_t <dt pn="section-3-3.15">STR_t</dt>
<dd pn="section-3-3.16">
the transformation that maps an integer i = 256<sup>t-1<
/sup> * i_1 + ... + 256 * i_{t-1} + i_t
into the byte string STR_t(i) = (i_1, ... , i_t) in B_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 b (the interpretation of the integer as a byte string in b
ig-endian format); ig-endian format).
</t> </dd>
<t hangText = "str_t"> <dt pn="section-3-3.17">str_t</dt>
the transformation that maps an integer i = 256^{t-1} * <dd pn="section-3-3.18">
i_t + ... + 256 * i_2 + i_1 the transformation that maps an integer i = 256<sup>t-1<
/sup> * i_t + ... + 256 * i_2 + i_1
into the byte string str_t(i) = (i_1, ... , i_t) in B_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 l (the interpretation of the integer as a byte string in l
ittle-endian format); ittle-endian format).
</t> </dd>
<t hangText = "INT"> <dt pn="section-3-3.19">INT</dt>
<dd pn="section-3-3.20">
the transformation that maps a string a = (a_1, ... , a_ t) in B_t the transformation that maps a string a = (a_1, ... , a_ t) in B_t
into the integer INT(a) = 256^{t-1} * a_1 + ... + 256 * into the integer INT(a) = 256<sup>t-1</sup> * a_1 + ...
a_{t-1} + a_t + 256 * a_{t-1} + a_t
(the interpretation of the byte string in big-endian for (the interpretation of the byte string in big-endian for
mat as an integer); mat as an integer).
</t> </dd>
<t hangText = "int"> <dt pn="section-3-3.21">int</dt>
<dd pn="section-3-3.22">
the transformation that maps a string a = (a_1, ... , a_ t) in B_t the transformation that maps a string a = (a_1, ... , a_ t) in B_t
into the integer int(a) = 256^{t-1} * a_t + ... + 256 * into the integer int(a) = 256<sup>t-1</sup> * a_t + ...
a_2 + a_1 + 256 * a_2 + a_1
(the interpretation of the byte string in little-endian (the interpretation of the byte string in little-endian
format as an integer); format as an integer).
</t> </dd>
<t hangText = "k"> <dt pn="section-3-3.23">k</dt>
the length of the block cipher key in bytes; <dd pn="section-3-3.24">
</t> the length of the block cipher key in bytes.
<t hangText = "n"> </dd>
the length of the block cipher block in bytes; <dt pn="section-3-3.25">n</dt>
</t> <dd pn="section-3-3.26">
<t hangText = "Q_c"> the length of the block cipher block in bytes.
the public key stored in the client's certificate; </dd>
</t> <dt pn="section-3-3.27">Q_c</dt>
<t hangText = "d_c"> <dd pn="section-3-3.28">
the private key that corresponds to the Q_c key; the public key stored in the client's certificate.
</t> </dd>
<t hangText = "Q_s"> <dt pn="section-3-3.29">d_c</dt>
the public key stored in the server's certificate; <dd pn="section-3-3.30">
</t> the private key that corresponds to the Q_c key.
<t hangText = "d_s"> </dd>
the private key that corresponds to the Q_s key; <dt pn="section-3-3.31">Q_s</dt>
</t> <dd pn="section-3-3.32">
<t hangText = "q_s"> the public key stored in the server's certificate.
an order of a cyclic subgroup of elliptic curve points g </dd>
roup containing point Q_s; <dt pn="section-3-3.33">d_s</dt>
</t> <dd pn="section-3-3.34">
<t hangText = "P_s"> the private key that corresponds to the Q_s key.
the distinguished generator of the subgroup of order q_s </dd>
that belongs to the same curve as Q_s; <dt pn="section-3-3.35">q_s</dt>
</t> <dd pn="section-3-3.36">
<t hangText = "r_c"> an order of a cyclic subgroup of the elliptic curve poin
the random string contained in ClientHello.random field ts group containing point Q_s.
(see <xref target="RFC5246"/>); </dd>
</t> <dt pn="section-3-3.37">P_s</dt>
<t hangText = "r_s"> <dd pn="section-3-3.38">
the random string contained in ServerHello.random field the distinguished generator of the subgroup of order q_s
(see <xref target="RFC5246"/>). that belongs to the same curve as Q_s.
</t> </dd>
</list> <dt pn="section-3-3.39">r_c</dt>
</t> <dd pn="section-3-3.40">
</section> the random string contained in the ClientHello.random fi
eld (see <xref target="RFC5246" format="default" sectionFormat="of" derivedConte
<section anchor="CSD" title="Cipher Suite Definitions"> nt="RFC5246"/>).
<t> </dd>
<dt pn="section-3-3.41">r_s</dt>
<dd pn="section-3-3.42">
the random string contained in the ServerHello.random fi
eld (see <xref target="RFC5246" format="default" sectionFormat="of" derivedConte
nt="RFC5246"/>).
</dd>
</dl>
</section>
<section anchor="CSD" numbered="true" toc="include" removeInRFC="false" pn="
section-4">
<name slugifiedName="name-cipher-suite-definitions">Cipher Suite Definitio
ns</name>
<t indent="0" pn="section-4-1">
This document specifies the CTR_OMAC cipher suites and the CNT_I MIT cipher suite. This document specifies the CTR_OMAC cipher suites and the CNT_I MIT cipher suite.
</t> </t>
<t> <t indent="0" pn="section-4-2">
The CTR_OMAC cipher suites have the following values: The CTR_OMAC cipher suites have the following values:
<list style = "empty"> </t>
<t> <sourcecode name="" type="" markers="false" pn="section-4-3">
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC = {0xC1, 0x TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC = {0xC1, 0x00};
00}; TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC = {0xC1, 0x01}.
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC = {0xC1, 0x01}. </sourcecode>
</t> <t indent="0" pn="section-4-4">
</list>
</t>
<t>
The CNT_IMIT cipher suite has the following value: The CNT_IMIT cipher suite has the following value:
<list style = "empty"> </t>
<t> <sourcecode name="" type="" markers="false" pn="section-4-5">
TLS_GOSTR341112_256_WITH_28147_CNT_IMIT = {0xC1, 0x02}. TLS_GOSTR341112_256_WITH_28147_CNT_IMIT = {0xC1, 0x02}.
</t> </sourcecode>
</list> <section anchor="RecordProtection" numbered="true" toc="include" removeInR
</t> FC="false" pn="section-4.1">
<section anchor ="RecordProtection" title ="Record Payload Protectio <name slugifiedName="name-record-payload-protection">Record Payload Prot
n"> ection</name>
<t> <t indent="0" pn="section-4.1-1">
The profile of TLS 1.2 with GOST algorithms requires that th The profile of TLS 1.2 with GOST algorithms requires that th
e compression is not used. e compression not be used.
</t> </t>
<t> <t indent="0" pn="section-4.1-2">
All of the cipher suites described in this document use such All of the cipher suites described in this document use such
modes of operation (see <xref target="EncryptionAlgorithm"/>) that protect the modes of operation (see <xref target="EncryptionAlgorithm" format="default" sec
records in the same way as if they were protected by a stream cipher. tionFormat="of" derivedContent="Section 4.3.3"/>) that protect the records in th
e same way as if they were protected by a stream cipher.
The TLSCiphertext structure for the CTR_OMAC and CNT_IMIT ci pher suites is specified The TLSCiphertext structure for the CTR_OMAC and CNT_IMIT ci pher suites is specified
in accordance with the Standard Stream Cipher case (see Sect in accordance with the standard stream cipher case (see <xre
ion 6.2.3.1 of <xref target="RFC5246"/>): f target="RFC5246" section="6.2.3.1" sectionFormat="of" format="default" derived
</t> Link="https://rfc-editor.org/rfc/rfc5246#section-6.2.3.1" derivedContent="RFC524
<t> 6"/>):
<figure>
<artwork> </t>
<![CDATA[ <sourcecode name="" type="asn.1" markers="false" pn="section-4.1-3">
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 length; uint16 length;
GenericStreamCipher fragment; GenericStreamCipher fragment;
} TLSCiphertext; } TLSCiphertext;
]]> </sourcecode>
</artwork> <t indent="0" pn="section-4.1-4">
</figure> where TLSCiphertext.fragment is generated in accordance with <xref tar
</t> get="TLSCiphertext_CTR_OMAC" format="default" sectionFormat="of" derivedContent=
<t> "Section 4.1.1"/> when the
where TLSCiphertext.fragment is generated in accordance with CTR_OMAC cipher suites are used and <xref target="TLSCiphertext_CNT_IMIT" format
<xref target="TLSCiphertext_CTR_OMAC"/> when the CTR_OMAC cipher suite is used ="default" sectionFormat="of" derivedContent="Section 4.1.2"/> when the CNT_IMIT
and <xref target="TLSCiphertext_CNT_IMIT"/> when the CNT_IMIT
cipher suite is used. cipher suite is used.
</t> </t>
<t> <t indent="0" pn="section-4.1-5">
The connection key material is a key material that The connection key material is a key material that
consists of the sender_write_key (either the client_write_ke y or the server_write_key), consists of the sender_write_key (either the client_write_ke y or the server_write_key),
the sender_write_MAC_key (either the client_write_MAC_key or the server_write_MAC_key) and the the sender_write_MAC_key (either the client_write_MAC_key or the server_write_MAC_key), and the
sender_write_IV (either the client_write_IV or the server_wr ite_IV) parameters sender_write_IV (either the client_write_IV or the server_wr ite_IV) parameters
that are generated in accordance with Section 6.3 of <xref t that are generated in accordance with <xref target="RFC5246"
arget="RFC5246"/>. section="6.3" sectionFormat="of" format="default" derivedLink="https://rfc-edit
</t> or.org/rfc/rfc5246#section-6.3" derivedContent="RFC5246"/>.
<t> </t>
The record key material is a key material that is generated <t indent="0" pn="section-4.1-6">
from the connection key material and is used to protect a record with the certai The record key material is a key material that is generated
n sequence number. from the connection key material and is used to protect a record with a certain
Note that with some cipher suites defined in this document t sequence number.
he record key material can be equal to the connection key material. Note that with some cipher suites defined in this document,
</t> the record key material can be equal to the connection key material.
<t> </t>
In this section the TLSCiphertext.fragment generation is des <t indent="0" pn="section-4.1-7">
cribed for one particular endpoint In this section, the TLSCiphertext.fragment generation is de
scribed for one particular endpoint
(server or client) with the corresponding connection key mat erial and record key material. (server or client) with the corresponding connection key mat erial and record key material.
</t> </t>
<section anchor ="TLSCiphertext_CTR_OMAC" title="CTR_OMAC"> <section anchor="TLSCiphertext_CTR_OMAC" numbered="true" toc="include" r
<t> emoveInRFC="false" pn="section-4.1.1">
In case of the CTR_OMAC cipher suites the record key mat <name slugifiedName="name-ctr_omac">CTR_OMAC</name>
erial differs from the connection key material, and for the sequence number seqn <t indent="0" pn="section-4.1.1-1">
um consists of: In the CTR_OMAC cipher suites, the record key material differ
</t> s from the connection key material, and for the seqnum sequence number consists
<t> of:
<list style="symbols"> </t>
<t> <sourcecode name="" type="" markers="false" pn="section-4.1.1-2">
K_ENC_seqnum in B_k; K_ENC_seqnum in B_k;
</t>
<t>
K_MAC_seqnum in B_k;
</t>
<t>
IV_seqnum in B_{n/2}.
</t>
</list>
</t>
<t>
The K_ENC_seqnum and K_MAC_seqnum values are calculated
using the TLSTREE function defined in <xref target="TLSTREE"/>,
the connection key material and the sequence number seqn
um. IV_seqnum is calculated by adding seqnum value to sender_write_IV modulo 2^{
(n/2)*8}:
</t>
<t>
<list style = "symbols">
<t>
K_ENC_seqnum = TLSTREE(sender_write_key, seqnum)
;
</t>
<t>
K_MAC_seqnum = TLSTREE(sender_write_MAC_key, seq
num);
</t>
<t>
IV_seqnum = STR_{n/2}((INT(sender_write_IV) + se
qnum) mod 2^{(n/2)*8}).
</t>
</list>
</t>
<t>
The TLSCiphertext.fragment that corresponds to the seqnu
m sequence number is calculated as follows:
</t>
<t>
1. The MACValue_seqnum value is generated using the MAC
algorithm (see <xref target="MAC"/>) similar to Section 6.2.3.1 of <xref target=
"RFC5246"/>
except the sender_write_MAC_key is replaced by the K_MAC
_seqnum key:
<list style = "empty">
<t>
MACValue_seqnum = MAC(K_MAC_seqnum, STR_8(seqnum
) | type_seqnum | version_seqnum | length_seqnum | fragment_seqnum),
</t>
</list>
</t>
<t>
where type_seqnum, version_seqnum, length_seqnum, fragme
nt_seqnum are the
TLSCompressed.type, TLSCompressed.version, TLSCompressed
.length and
TLSCompressed.fragment values of the record with the seq
num sequence number.
</t>
<t>
2. The entire data with the MACValue is encrypted with t
he ENC stream cipher (see <xref target="EncryptionAlgorithm"/>):
<list style = "empty">
<t>
ENCValue_seqnum = ENC(K_ENC_seqnum, IV_seqnum, f
ragment_seqnum | MACValue_seqnum),
</t>
</list>
</t>
<t>
where fragment_seqnum is the TLSCompressed.fragment valu
e of the record with the seqnum sequence number.
</t>
<t>
3. The fields of the GenericStreamCipher structure (see
section 6.2.3.1 of <xref target="RFC5246"/>) for the TLSCiphertext.fragment valu
e are defined by the ENCValue_seqnum value:
</t>
<t>
<list style = "empty">
<t>
TLSCiphertext.fragment.content = ENCValue_seqnum
[1..length_seqnum],
</t>
<t>
TLSCiphertext.fragment.MAC = ENCValue_seqnum[le
ngth_seqnum + 1..length_seqnum + mac_length],
</t>
</list>
</t>
<t>
where length_seqnum is the TLSCompressed.length value of
the record with the seqnum sequence number, mac_length is equal to 16 for the T
LS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite and
8 for the TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC cipher
suite.
</t>
<t>
Note that the CTR_OMAC cipher suites use the authenticat
e-then-encrypt method (see Appendix F.4 of <xref target="RFC5246"/>). Since the
se ciphers are functioning as stream ciphers, the authenticate-then-encrypt meth
od is
secure, and, as specified by <xref target="RFC7366"/>, t
he server that selects the CTR_OMAC ciphers MUST NOT send an encrypt_then_mac ex
tension to the client.
</t>
</section> K_MAC_seqnum in B_k; and
<section anchor ="TLSCiphertext_CNT_IMIT" title="CNT_IMIT"> IV_seqnum in B_{n/2}.
<t> </sourcecode>
In case of the CNT_IMIT cipher suite the record key mate <t indent="0" pn="section-4.1.1-3">
rial is equal to the connection key material and consists of: The K_ENC_seqnum and K_MAC_seqnum values are calculated
</t> using the TLSTREE function defined in <xref target="TLSTREE" format="default" se
<t> ctionFormat="of" derivedContent="Section 8.1"/>,
<list style="symbols"> the connection key material, and the seqnum sequence num
<t> ber . IV_seqnum is calculated by adding the seqnum value to sender_write_IV modu
sender_write_key in B_k; lo 2<sup>(n/2)*8</sup>:
</t> </t>
<t> <sourcecode name="" type="" markers="false" pn="section-4.1.1-4">
sender_write_MAC_key in B_k; K_ENC_seqnum = TLSTREE(sender_write_key, seqnum);
</t>
<t>
sender_write_IV in B_n.
</t>
</list>
</t>
<t>
The TLSCiphertext.fragment that corresponds to the seqnu
m sequence number is calculated as follows:
</t>
<t>
1. The MACValue_seqnum value is generated by the MAC alg
orithm (see <xref target="MAC"/>) as follows:
</t>
<t>
<list style = "empty">
<t>
MACValue_seqnum = MAC(sender_write_MAC_key, STR_
8(0) | type_0 | version_0 | length_0 | fragment_0 | ... | STR_8(seqnum) | type_s
eqnum | version_seqnum | length_seqnum | fragment_seqnum),
</t>
</list>
</t>
<t>
where type_i, version_i, length_i, fragment_i, i in {0,
... , seqnum}, are the
TLSCompressed.type, TLSCompressed.version, TLSCompressed
.length and TLSCompressed.fragment values of the record with the i sequence numb
er.
</t>
<t>
Due to the use of the CBC-MAC based mode (see <xref targ
et="MAC"/>) producing the
MACValue_seqnum value does not mean processing all previ
ous records. It is enough to store only an
intermediate internal state of the MAC algorithm.
</t>
<t>
2. The entire data with the MACValue is encrypted with t
he ENC stream cipher (see <xref target="EncryptionAlgorithm"/>):
</t>
<t>
<list style = "empty">
<t>
ENCValue_0 | ... | ENCValue_seqnum = ENC(sender_
write_key, sender_write_IV, fragment_0 | MACValue_0 | ... | fragment_seqnum | MA
CValue_seqnum),
</t>
</list>
</t>
<t>
where the length of the byte string ENCValue_i in bytes
is equal to the length of the byte string (fragment_i | MACValue_i) in bytes, i
in {0, ... , seqnum}.
</t>
<t>
Due to the use of the stream cipher (see <xref target="E
ncryptionAlgorithm"/>) producing the
ENCValue_seqnum value does not mean processing all previ
ous records. It is enough to store only an intermediate
internal state of the ENC stream cipher.
</t>
<t>
3. The fields of the GenericStreamCipher structure (see
section 6.2.3.1 of <xref target="RFC5246"/>) for the TLSCiphertext.fragment valu
e are defined by the ENCValue_seqnum value:
</t>
<t>
<list style = "empty">
<t>
TLSCiphertext.fragment.content = ENCValue_seqnum
[1..length_seqnum],
</t>
<t>
TLSCiphertext.fragment.MAC = ENCValue_seqnum[le
ngth_seqnum + 1..length_seqnum + mac_length],
</t>
</list>
</t>
<t>
where length_seqnum is the TLSCompressed.length value of
the record with the seqnum sequence number, mac_length is equal to 4.
</t>
<t>
Note that the CNT_IMIT cipher suite uses the authenticat
e-then-encrypt method (see Appendix F.4 of <xref target="RFC5246"/>). Since thi
s cipher is functioning as a stream cipher, the authenticate-then-encrypt method
is secure, and, as specified by <xref target="RFC7366"/>,
the server that selects the CNT_IMIT cipher MUST NOT sen
d an encrypt_then_mac extension to the client.
</t>
</section>
</section>
<section title="Key Exchange and Authentication"> K_MAC_seqnum = TLSTREE(sender_write_MAC_key, seqnum); and
<t>
The cipher suites defined in this document use a key encapsu
lation mechanism based on Diffie-Hellman to share the TLS premaster secret.
</t>
<t>
<figure>
<artwork> <![CDATA[
Client Server
ClientHello --------> IV_seqnum = STR_{n/2}((INT(sender_write_IV) + seqnum)
ServerHello mod 2^({(n/2)*8}).
Certificate </sourcecode>
CertificateRequest* <t indent="0" pn="section-4.1.1-5">
<-------- ServerHelloDone The TLSCiphertext.fragment that corresponds to the seqnum sequence number is ca
Certificate* lculated as follows:
ClientKeyExchange </t>
CertificateVerify* <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-
[ChangeCipherSpec] 4.1.1-6">
Finished --------> <li pn="section-4.1.1-6.1" derivedCounter="1.">
[ChangeCipherSpec] <t indent="0" pn="section-4.1.1-6.1.1">The MACValue_seqnum value i
<-------- Finished s generated using the Message Authentication Code (MAC) algorithm (see <xref tar
Application Data <-------> Application Data get="MAC" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>)
similar to <xref target="RFC5246" section="6.2.3.1" sectionFormat="of" format="d
efault" derivedLink="https://rfc-editor.org/rfc/rfc5246#section-6.2.3.1" derived
Content="RFC5246"/>, except the sender_write_MAC_key is replaced by the K_MAC_se
qnum key:</t>
<sourcecode name="" type="" markers="false" pn="section-4.1.1-6.1.
2">
MACValue_seqnum = MAC(K_MAC_seqnum, STR_8(seqnum) | type_seqnum |
version_seqnum | length_seqnum | fragment_seqnum),
</sourcecode>
<t indent="0" pn="section-4.1.1-6.1.3">
where type_seqnum, version_seqnum, length_seqnum, and fragment_seqnum are the TL
SCompressed.type, TLSCompressed.version, TLSCompressed.length, and TLSCompressed
.fragment values of the record with the seqnum sequence number.
</t>
</li>
<li pn="section-4.1.1-6.2" derivedCounter="2.">
<t indent="0" pn="section-4.1.1-6.2.1">
The entire data with the MACValue is encrypted with the ENC stream cipher (see <
xref target="EncryptionAlgorithm" format="default" sectionFormat="of" derivedCon
tent="Section 4.3.3"/>):
</t>
<sourcecode name="" type="" markers="false" pn="section-4.1.1-6.2.
2">
ENCValue_seqnum = ENC(K_ENC_seqnum, IV_seqnum, fragment_seqnum |
MACValue_seqnum),
</sourcecode>
<t indent="0" pn="section-4.1.1-6.2.3">
where fragment_seqnum is the TLSCompressed.fragment value of the record with the
seqnum sequence number.
</t>
</li>
<li pn="section-4.1.1-6.3" derivedCounter="3.">
<t indent="0" pn="section-4.1.1-6.3.1">
The fields of the GenericStreamCipher structure (see <xref target="RFC5246" sect
ionFormat="of" section="6.2.3.1" format="default" derivedLink="https://rfc-edito
r.org/rfc/rfc5246#section-6.2.3.1" derivedContent="RFC5246"/>) for the TLSCipher
text.fragment value are defined by the ENCValue_seqnum value:
</t>
<sourcecode name="" type="" markers="false" pn="section-4.1.1-6.3.
2">
TLSCiphertext.fragment.content =
ENCValue_seqnum[1..length_seqnum],
Figure 1: Message flow for a full handshake. TLSCiphertext.fragment.MAC = ENCValue_seqnum[length_seqnum +
1..length_seqnum + mac_length],
</sourcecode>
<t indent="0" pn="section-4.1.1-6.3.3">
where length_seqnum is the TLSCompressed.length value of
the record with the seqnum sequence number and mac_length is equal to 16 for th
e TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite and 8 for the TLS_GO
STR341112_256_WITH_MAGMA_CTR_OMAC cipher suite.
</t>
</li>
</ol>
<t indent="0" pn="section-4.1.1-7">
Note that the CTR_OMAC cipher suites use the authenticat
e-then-encrypt method (see <xref target="RFC5246" sectionFormat="of" section="F.
4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5246#appendix-F.4
" derivedContent="RFC5246"/>). Since these ciphers are functioning as stream cip
hers, the authenticate-then-encrypt method is
secure, and as specified by <xref target="RFC7366" forma
t="default" sectionFormat="of" derivedContent="RFC7366"/>, the server that selec
ts the CTR_OMAC ciphers <bcp14>MUST NOT</bcp14> send an encrypt_then_mac extensi
on to the client.
</t>
</section>
<section anchor="TLSCiphertext_CNT_IMIT" numbered="true" toc="include" r
emoveInRFC="false" pn="section-4.1.2">
<name slugifiedName="name-cnt_imit">CNT_IMIT</name>
<t indent="0" pn="section-4.1.2-1">
In the CNT_IMIT cipher suite, the record key material is
equal to the connection key material and consists of:
</t>
<sourcecode name="" type="" markers="false" pn="section-4.1.2-2">
sender_write_key in B_k;
* Indicates optional messages that are sent for sender_write_MAC_key in B_k; and
the client authentication.
Note: To help avoid pipeline stalls, ChangeCipherSpec is an sender_write_IV in B_n.
independent TLS protocol content type, and is not actually </sourcecode>
a TLS handshake message. <t indent="0" pn="section-4.1.2-3">
The TLSCiphertext.fragment that corresponds to the seqnum sequence number is cal
culated as follows:
</t>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-
4.1.2-4">
<li pn="section-4.1.2-4.1" derivedCounter="1.">
<t indent="0" pn="section-4.1.2-4.1.1">
The MACValue_seqnum value is generated by the MAC algorithm (see <xref target="M
AC" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>) as fol
lows:
</t>
<sourcecode name="" type="" markers="false" pn="section-4.1.2-4.1.
2">
MACValue_seqnum = MAC(sender_write_MAC_key, STR_8(0) | type_0 |
version_0 | length_0 | fragment_0 | ... | STR_8(seqnum) |
type_seqnum | version_seqnum | length_seqnum | fragment_seqnum),
</sourcecode>
<t indent="0" pn="section-4.1.2-4.1.3">
where type_i, version_i, length_i, fragment_i, and i in {0, ... , seqnum} are th
e
TLSCompressed.type, TLSCompressed.version, TLSCompressed
.length, and TLSCompressed.fragment values of the record with the i sequence num
ber.
</t>
<t indent="0" pn="section-4.1.2-4.1.4">
Due to the use of the mode based on Cipher Block Chaining MAC (CBC-MAC) (see <xr
ef target="MAC" format="default" sectionFormat="of" derivedContent="Section 4.3.
2"/>), producing the
MACValue_seqnum value does not mean processing all previ
ous records. It is enough to store only an
intermediate internal state of the MAC algorithm.
</t>
</li>
<li pn="section-4.1.2-4.2" derivedCounter="2.">
<t indent="0" pn="section-4.1.2-4.2.1">
The entire data with the MACValue is encrypted with the ENC stream ci
pher (see <xref target="EncryptionAlgorithm" format="default" sectionFormat="of"
derivedContent="Section 4.3.3"/>):
</t>
<sourcecode name="" type="" markers="false" pn="section-4.1.2-4.2.
2">
ENCValue_0 | ... | ENCValue_seqnum = ENC(sender_write_key,
sender_write_IV, fragment_0 | MACValue_0 | ... | fragment_seqnum |
MACValue_seqnum),
</sourcecode>
<t indent="0" pn="section-4.1.2-4.2.3">
where the length of the byte string ENCValue_i in bytes
is equal to the length of the byte string (fragment_i | MACValue_i) in bytes and
i in {0, ... , seqnum}.
</t>
<t indent="0" pn="section-4.1.2-4.2.4">
Due to the use of the stream cipher (see <xref target="E
ncryptionAlgorithm" format="default" sectionFormat="of" derivedContent="Section
4.3.3"/>), producing the
ENCValue_seqnum value does not mean processing all previ
ous records. It is enough to store only an intermediate
internal state of the ENC stream cipher.
</t>
</li>
<li pn="section-4.1.2-4.3" derivedCounter="3.">
<t indent="0" pn="section-4.1.2-4.3.1">
The fields of the GenericStreamCipher structure (see <xref target="RFC5246" sect
ionFormat="of" section="6.2.3.1" format="default" derivedLink="https://rfc-edito
r.org/rfc/rfc5246#section-6.2.3.1" derivedContent="RFC5246"/>) for the TLSCipher
text.fragment value are defined by the ENCValue_seqnum value:
</t>
<sourcecode name="" type="" markers="false" pn="section-4.1.2-4.3.
2">
TLSCiphertext.fragment.content =
ENCValue_seqnum[1..length_seqnum],
]]></artwork> TLSCiphertext.fragment.MAC = ENCValue_seqnum[length_seqnum +
</figure> 1..length_seqnum + mac_length],
</t> </sourcecode>
<t> <t indent="0" pn="section-4.1.2-4.3.3">
Figure 1 shows all messages involved in the TLS key establis where length_seqnum is the TLSCompressed.length value of
hment protocol (full handshake). the record with the seqnum sequence number, and mac_length is equal to 4.
A ServerKeyExchange MUST NOT be sent (the server's certifica </t>
te </li>
contains enough data to allow client to exchange the premast </ol>
er secret). <t indent="0" pn="section-4.1.2-5">
</t> Note that the CNT_IMIT cipher suite uses the authenticat
<t> e-then-encrypt method (see <xref target="RFC5246" sectionFormat="of" section="F.
The server side of the channel is always authenticated; the 4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5246#appendix-F.4
client side is optionally authenticated. " derivedContent="RFC5246"/>). Since this cipher is functioning as a stream ciph
The server is authenticated by proving that it knows the pre er, the authenticate-then-encrypt method is secure, and as specified by <xref ta
master secret that is encrypted with the public key Q_s from the server's certif rget="RFC7366" format="default" sectionFormat="of" derivedContent="RFC7366"/>,
icate. the server that selects the CNT_IMIT cipher <bcp14>MUST
The client is authenticated via its signature over the hands NOT</bcp14> send an encrypt_then_mac extension to the client.
hake transcript. </t>
</t> </section>
<t> </section>
In general the key exchange process for both CTR_OMAC and CN <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2
T_IMIT cipher suites consists of the following steps: ">
<list style="numbers"> <name slugifiedName="name-key-exchange-and-authentica">Key Exchange and
<t> Authentication</name>
<t indent="0" pn="section-4.2-1">
The cipher suites defined in this document use a key encapsulation m
echanism based on Diffie-Hellman to share the TLS preliminary secret.
</t>
<figure anchor="fig1" align="left" suppress-title="false" pn="figure-1">
<name slugifiedName="name-message-flow-for-a-full-han">Message Flow fo
r a Full Handshake</name>
<artwork name="" type="tls-presentation" alt="" align="left" pn="secti
on-4.2-2.1">
Client Server
ClientHello --------&gt;
ServerHello
Certificate
CertificateRequest*
&lt;-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished --------&gt;
[ChangeCipherSpec]
&lt;-------- Finished
Application Data &lt;-------&gt; Application Data
</artwork>
</figure>
<t indent="0" pn="section-4.2-3">Notes for <xref target="fig1" format="d
efault" sectionFormat="of" derivedContent="Figure 1"/>:</t>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4.
2-4">
<li pn="section-4.2-4.1" derivedCounter="1."> "*" indicates optional m
essages that are sent for
the client authentication.</li>
<li pn="section-4.2-4.2" derivedCounter="2.">To help avoid pipeline st
alls, ChangeCipherSpec is an
independent TLS protocol content type and is not actually
a TLS handshake message.</li>
</ol>
<t indent="0" pn="section-4.2-5"><xref target="fig1" format="default" se
ctionFormat="of" derivedContent="Figure 1"/> shows all messages involved in the
TLS key establishment protocol (full handshake).
A ServerKeyExchange <bcp14>MUST NOT</bcp14> be sent (the ser
ver's certificate
contains enough data to allow the client to exchange the pre
liminary secret).
</t>
<t indent="0" pn="section-4.2-6">
The server side of the channel is always authenticated; the client s
ide is optionally authenticated.
The server is authenticated by proving that it knows the preliminary
secret that is encrypted with the public key Q_s from the server's certificate.
The client is authenticated via its signature over the handshake tra
nscript.
</t>
<t indent="0" pn="section-4.2-7">
In general, the key exchange process for both the CTR_OMAC a
nd CNT_IMIT cipher suites consists of the following steps:
</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.
2-8"><li pn="section-4.2-8.1" derivedCounter="1.">
The client generates the ephemeral key pair (d_eph, Q_eph) that corresponds to the server's public key Q_s stored in its certificate . The client generates the ephemeral key pair (d_eph, Q_eph) that corresponds to the server's public key Q_s stored in its certificate .
</t> </li>
<t> <li pn="section-4.2-8.2" derivedCounter="2.">
The client generates the premaster secret PS. The PS The client generates the preliminary secret PS. The
value is chosen from B_32 at random. PS value is chosen from B_32 at random.
</t> </li>
<t> <li pn="section-4.2-8.3" derivedCounter="3.">
Using d_eph and Q_s the client generates the export Using d_eph and Q_s, the client generates the export
key material (see <xref target="CTRkeygen"/> and <xref target="CNTkeygen"/>) key material (see Sections <xref target="CTRkeygen" format="counter" sectionFor
for the particular key export algorithm (see <xref t mat="of" derivedContent="4.2.4.1"/> and <xref target="CNTkeygen" format="counter
arget="KExpImp15"/> and <xref target="KExpImp28147"/>) " sectionFormat="of" derivedContent="4.2.4.2"/>)
for the particular key export algorithm (see Section
s <xref target="KExpImp15" format="counter" sectionFormat="of" derivedContent="8
.2.1"/> and <xref target="KExpImp28147" format="counter" sectionFormat="of" deri
vedContent="8.2.2"/>)
to generate the export representation PSExp of the P S value. to generate the export representation PSExp of the P S value.
</t> </li>
<t> <li pn="section-4.2-8.4" derivedCounter="4.">
The client sends its ephemeral public key Q_eph and PSExp value in the ClientKeyExchange message. The client sends its ephemeral public key Q_eph and PSExp value in the ClientKeyExchange message.
</t> </li>
<t> <li pn="section-4.2-8.5" derivedCounter="5.">
Using its private key d_s the server generates the i Using its private key d_s, the server generates the
mport key material (see <xref target="CTRkeygen"/> and <xref target="CNTkeygen"/ import key material (see Sections <xref target="CTRkeygen" format="counter" sect
>) ionFormat="of" derivedContent="4.2.4.1"/> and <xref target="CNTkeygen" format="c
for the particular key import algorithm (see <xref t ounter" sectionFormat="of" derivedContent="4.2.4.2"/>)
arget="KExpImp15"/> and <xref target="KExpImp28147"/>) for the particular key import algorithm (see Section
to extract the premaster secret PS from the export r s <xref target="KExpImp15" format="counter" sectionFormat="of" derivedContent="8
epresentation PSExp. .2.1"/> and <xref target="KExpImp28147" format="counter" sectionFormat="of" deri
</t> vedContent="8.2.2"/>)
</list> to extract the preliminary secret PS from the export
</t> representation PSExp.
</li>
<t> </ol>
<t indent="0" pn="section-4.2-9">
This section specifies the data structures and computations used by the profile of TLS 1.2 with GOST algorithms. This section specifies the data structures and computations used by the profile of TLS 1.2 with GOST algorithms.
The specifications for the ClientHello, ServerHello, server Certificate, CertificateRequest, ClientKeyExchange, CertificateVerify and The specifications for the ClientHello, ServerHello, Server Certificate, CertificateRequest, ClientKeyExchange, CertificateVerify, and
Finished handshake messages are described in further detail below. Finished handshake messages are described in further detail below.
</t> </t>
<section anchor="Hello" title="Hello Messages"> <section anchor="Hello" numbered="true" toc="include" removeInRFC="false
<t> " pn="section-4.2.1">
The ClientHello message is generated in accordance with <name slugifiedName="name-hello-messages">Hello Messages</name>
Section 7.4.1.2 of <xref target="RFC5246"/> and must meet the following requirem <t indent="0" pn="section-4.2.1-1">
ents: The ClientHello message is generated in accordance with
<list style="symbols"> <xref target="RFC5246" section="7.4.1.2" sectionFormat="of" format="default" der
<t> ivedLink="https://rfc-editor.org/rfc/rfc5246#section-7.4.1.2" derivedContent="RF
The ClientHello.compression_methods field MUST c C5246"/> and must meet the following requirements:
ontain exactly one byte, set to zero, which corresponds to the "null" compressio </t>
n method. <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
</t> -4.2.1-2">
<t> <li pn="section-4.2.1-2.1">
The ClientHello.extensions field MUST contain th The ClientHello.compression_methods field <bcp14
e signature_algorithms extension (see <xref target="RFC5246"/>). >MUST</bcp14> contain exactly one byte, set to zero, which corresponds to the "n
<vspace/> ull" compression method.
<vspace/> </li>
If the negotiated cipher suite is one of CTR_OMA <li pn="section-4.2.1-2.2">
C/CTR_IMIT and the signature_algorithms extension in the ClientHello message doe <t indent="0" pn="section-4.2.1-2.2.1">
s not contain the values defined in <xref target="SAR"/>, The ClientHello.extensions field <bcp14>MUST</bc
the server MUST either abort the connection or i p14> contain the signature_algorithms extension (see <xref target="RFC5246" form
gnore this extension and behave as if at="default" sectionFormat="of" derivedContent="RFC5246"/>).
</t>
<t indent="0" pn="section-4.2.1-2.2.2">
If the negotiated cipher suite is one of CTR_OMA
C/CTR_IMIT and the signature_algorithms extension in the ClientHello message doe
s not contain the values defined in <xref target="SAR" format="default" sectionF
ormat="of" derivedContent="Section 5"/>,
the server <bcp14>MUST</bcp14> either abort the
connection or ignore this extension and behave as if
the client had sent the signature_algorithms ext ension with the values {8, 64} and {8, 65}. the client had sent the signature_algorithms ext ension with the values {8, 64} and {8, 65}.
</t> </t>
</list> </li>
</t> </ul>
<t> <t indent="0" pn="section-4.2.1-3">
The ServerHello message is generated in accordance with The ServerHello message is generated in accordance with
Section 7.4.1.3 of <xref target="RFC5246"/> and must meet the following requirem <xref target="RFC5246" section="7.4.1.3" sectionFormat="of" format="default" der
ents: ivedLink="https://rfc-editor.org/rfc/rfc5246#section-7.4.1.3" derivedContent="RF
<list style="symbols"> C5246"/> and must meet the following requirements:
<t> </t>
The ServerHello.compression_method field MUST co <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
ntain exactly one byte, set to zero, which corresponds to the "null" compression -4.2.1-4">
method. <li pn="section-4.2.1-4.1">
</t> The ServerHello.compression_method field <bcp14>
<t> MUST</bcp14> contain exactly one byte, set to zero, which corresponds to the "nu
The ServerHello.extensions field MUST NOT contai ll" compression method.
n the encrypt_then_mac extension (see <xref target="RFC7366"/>). </li>
</t> <li pn="section-4.2.1-4.2">
</list> The ServerHello.extensions field <bcp14>MUST NOT
</t> </bcp14> contain the encrypt_then_mac extension (see <xref target="RFC7366" form
</section> at="default" sectionFormat="of" derivedContent="RFC7366"/>).
<section title="Server Certificate"> </li>
<t> </ul>
This message is used to authentically convey the server' </section>
s <section numbered="true" toc="include" removeInRFC="false" pn="section-4
public key Q_s to the client and is generated in accorda .2.2">
nce with Section 7.4.2 of <xref target="RFC5246"/>. <name slugifiedName="name-server-certificate">Server Certificate</name
</t> >
<t> <t indent="0" pn="section-4.2.2-1"> This message is used to authentica
Upon receiving this message the client validates the cer lly convey the server's
tificate chain, extracts the server's public key Q_s to the client and is generated in accorda
nce with <xref target="RFC5246" section="7.4.2" sectionFormat="of" format="defau
lt" derivedLink="https://rfc-editor.org/rfc/rfc5246#section-7.4.2" derivedConten
t="RFC5246"/>.</t>
<t indent="0" pn="section-4.2.2-2"> Upon receiving this message, the c
lient validates the certificate chain, extracts the server's
public key, and checks that the key type is appropriate for the public key, and checks that the key type is appropriate for the
negotiated key exchange algorithm. (A possible reason fo r a fatal negotiated key exchange algorithm. (A possible reason fo r a fatal
handshake failure is that the client's capabilities for handling handshake failure is that the client's capabilities for handling
elliptic curves and point formats are exceeded). elliptic curves and point formats are exceeded).</t>
</t> </section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-4
<section title="CertificateRequest"> .2.3">
<t> <name slugifiedName="name-certificaterequest">CertificateRequest</name
This message is sent by the server when requesting clien >
t authentication and is generated in accordance with Section 7.4.4 of <xref targ <t indent="0" pn="section-4.2.3-1"> This message is sent by the server
et="RFC5246"/>. when requesting client authentication and is generated in accordance with <xref
</t> target="RFC5246" section="7.4.4" sectionFormat="of" format="default" derivedLin
<t> k="https://rfc-editor.org/rfc/rfc5246#section-7.4.4" derivedContent="RFC5246"/>.
If the CTR_OMAC or CNT_IMIT cipher suite is negotiated, </t>
the CertificateRequest message MUST meet the following requirements: <t indent="0" pn="section-4.2.3-2">
<list style="symbols">
<t>
the CertificateRequest.supported_signature_algor
ithm field MUST contain only signature/hash algorithm pairs with the values {8,
64} or {8, 65} defined in <xref target="SAR"/>;
</t>
<t>
the CertificateRequest.certificate_types field M
UST contain only the gost_sign256 (67) or gost_sign512 (68) values defined in <x
ref target="CTIR"/>.
</t>
</list>
</t>
</section>
<section title="ClientKeyExchange"> If the CTR_OMAC or CNT_IMIT cipher suite is negotiated,
<t> the CertificateRequest message <bcp14>MUST</bcp14> meet the following requiremen
The ClientKeyExchange message is defined as follows. ts:
</t> </t>
<t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<figure> -4.2.3-3">
<artwork> <li pn="section-4.2.3-3.1">
<![CDATA[ the CertificateRequest.supported_signature_algor
ithm field <bcp14>MUST</bcp14> contain only signature/hash algorithm pairs with
the values {8, 64} or {8, 65} defined in <xref target="SAR" format="default" sec
tionFormat="of" derivedContent="Section 5"/>;
</li>
<li pn="section-4.2.3-3.2">
the CertificateRequest.certificate_types field <
bcp14>MUST</bcp14> contain only the gost_sign256 (67) or gost_sign512 (68) value
s defined in <xref target="CTIR" format="default" sectionFormat="of" derivedCont
ent="Section 7"/>.
</li>
</ul>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4
.2.4">
<name slugifiedName="name-clientkeyexchange">ClientKeyExchange</name>
<t indent="0" pn="section-4.2.4-1">
The ClientKeyExchange message is defined as follows:
</t>
<sourcecode name="" type="asn.1" markers="false" pn="section-4.2.4-2">
enum { vko_kdf_gost, vko_gost } KeyExchangeAlgorithm; enum { vko_kdf_gost, vko_gost } KeyExchangeAlgorithm;
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case vko_kdf_gost: GostKeyTransport; case vko_kdf_gost: GostKeyTransport;
case vko_gost: TLSGostKeyTransportBlob; case vko_gost: TLSGostKeyTransportBlob;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
]]> </sourcecode>
</artwork> <t indent="0" pn="section-4.2.4-3">
</figure> The body of the ClientKeyExchange message consists of a
</t> GostKeyTransport/TLSGostKeyTransportBlob structure that contains an export repre
<t> sentation of the preliminary secret PS.
The body of the ClientKeyExchange message consists of a </t>
GostKeyTransport/TLSGostKeyTransportBlob structure that contains an export repre <t indent="0" pn="section-4.2.4-4">
sentation of the premaster secret PS. The GostKeyTransport structure corresponds to the CTR_OM
</t> AC cipher suites and is described in <xref target="CTRkeygen" format="default" s
<t> ectionFormat="of" derivedContent="Section 4.2.4.1"/>, and
The GostKeyTransport structure corresponds to the CTR_OM the TLSGostKeyTransportBlob structure corresponds to the
AC cipher suites and is described in <xref target="CTRkeygen"/> and CNT_IMIT cipher suite and is described in <xref target="CNTkeygen" format="defa
the TLSGostKeyTransportBlob structure corresponds to CNT ult" sectionFormat="of" derivedContent="Section 4.2.4.2"/>.
_IMIT cipher suite and is described in <xref target="CNTkeygen"/>. </t>
</t> <t indent="0" pn="section-4.2.4-5">
<t>
The DER encoding rules are used to encode the GostKeyTra nsport and the TLSGostKeyTransportBlob structures. The DER encoding rules are used to encode the GostKeyTra nsport and the TLSGostKeyTransportBlob structures.
</t> </t>
<section anchor ="CTRkeygen" title ="CTR_OMAC"> <section anchor="CTRkeygen" numbered="true" toc="include" removeInRFC=
<t> "false" pn="section-4.2.4.1">
In case of the CTR_OMAC cipher suites the body of th <name slugifiedName="name-ctr_omac-2">CTR_OMAC</name>
e ClientKeyExchange message consists of the GostKeyTransport structure that is d <t indent="0" pn="section-4.2.4.1-1">
efined bellow. In the CTR_OMAC cipher suites, the body of the Clien
</t> tKeyExchange message consists of the GostKeyTransport structure that is defined
<t> below.
</t>
<t indent="0" pn="section-4.2.4.1-2">
The client generates the ClientKeyExchange message i n accordance with the following steps: The client generates the ClientKeyExchange message i n accordance with the following steps:
</t> </t>
<t> <ol indent="adaptive" spacing="normal" start="1" type="1" pn="sectio
1. Generates the ephemeral key pair (Q_eph, d_eph), n-4.2.4.1-3">
where: <li pn="section-4.2.4.1-3.1" derivedCounter="1.">
<list style="empty"> <t indent="0" pn="section-4.2.4.1-3.1.1">
<t> Generates the ephemeral key pair (Q_eph, d_eph), where:
d_eph is chosen from {1, ... , q_s - 1} at r </t>
andom; <sourcecode name="" type="" markers="false" pn="section-4.2.4.1-
</t> 3.1.2">
<t> d_eph is chosen from {1, ... , q_s - 1} at random;
Q_eph = d_eph * P_s.
</t>
</list>
</t>
<t>
2. Generates the premaster secret PS, where PS is ch
osen from B_32 at random.
</t>
<t>
3. Generates export keys (K_EXP_MAC and K_EXP_ENC) u
sing the KEG algorithm defined in <xref target="KEG"/>:
<list style="empty">
<t>
H = HASH(r_c | r_s);
</t>
<t>
K_EXP_MAC | K_EXP_ENC = KEG(d_eph, Q_s, H).
</t>
</list>
</t>
<t>
4. Generates an export representation PSExp of the p
remaster secret PS using the KExp15 algorithm defined in <xref target ="KExpImp1
5"/>:
<list style="empty">
<t>
IV = H[25..24 + n / 2];
</t>
<t>
PSExp = KExp15(PS, K_EXP_MAC, K_EXP_ENC, IV)
.
</t>
</list>
</t>
<t>
5. Generates the ClientKeyExchange message using the
GostKeyTransport structure that is defined as follows:
</t>
<figure>
<artwork>
<![CDATA[
Q_eph = d_eph * P_s.
</sourcecode>
</li>
<li pn="section-4.2.4.1-3.2" derivedCounter="2.">
<t indent="0" pn="section-4.2.4.1-3.2.1">
Generates the preliminary secret PS, where PS is chosen from B_32 at random.
</t>
</li>
<li pn="section-4.2.4.1-3.3" derivedCounter="3.">
<t indent="0" pn="section-4.2.4.1-3.3.1">
Generates export keys (K_EXP_MAC and K_EXP_ENC) using the KEG algorithm defined
in <xref target="KEG" format="default" sectionFormat="of" derivedContent="Sectio
n 8.3.1"/>:
</t>
<sourcecode name="" type="" markers="false" pn="section-4.2.4.1-
3.3.2">
H = HASH(r_c | r_s);
K_EXP_MAC | K_EXP_ENC = KEG(d_eph, Q_s, H).
</sourcecode>
</li>
<li pn="section-4.2.4.1-3.4" derivedCounter="4.">
<t indent="0" pn="section-4.2.4.1-3.4.1">
Generates an export representation PSExp of the preliminary
secret PS using the KExp15 algorithm defined in <xref target="KExpImp15" format=
"default" sectionFormat="of" derivedContent="Section 8.2.1"/>:
</t>
<sourcecode name="" type="" markers="false" pn="section-4.2.4.1-
3.4.2">
IV = H[25..24 + n / 2];
PSExp = KExp15(PS, K_EXP_MAC, K_EXP_ENC, IV).
</sourcecode>
</li>
<li pn="section-4.2.4.1-3.5" derivedCounter="5.">
<t indent="0" pn="section-4.2.4.1-3.5.1">
Generates the ClientKeyExchange message using the Gos
tKeyTransport structure that is defined as follows:
</t>
<sourcecode name="" type="asn.1" markers="false" pn="section-4.2
.4.1-3.5.2">
GostKeyTransport ::= SEQUENCE { GostKeyTransport ::= SEQUENCE {
keyExp OCTET STRING, keyExp OCTET STRING,
ephemeralPublicKey SubjectPublicKeyInfo, ephemeralPublicKey SubjectPublicKeyInfo,
ukm OCTET STRING OPTIONAL ukm OCTET STRING OPTIONAL
} }
SubjectPublicKeyInfo ::= SEQUENCE { SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier, algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING subjectPublicKey BIT STRING
} }
AlgorithmIdentifier ::= SEQUENCE { AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, algorithm OBJECT IDENTIFIER,
parameters ANY OPTIONAL parameters ANY OPTIONAL
} }
]]> </sourcecode>
</artwork> <t indent="0" pn="section-4.2.4.1-3.5.3">
</figure> where the keyExp field contains the PSExp value, the
<t> ephemeralPublicKey field contains the Q_eph value, and the ukm field <bcp14>MUS
where the keyExp field contains the PSExp value, the T</bcp14> be ignored by the server.
ephemeralPublicKey field contains the Q_eph value and the ukm field MUST be ign </t>
ored by the server. </li>
</t> </ol>
<t> <t indent="0" pn="section-4.2.4.1-4">
Upon receiving the ClientKeyExchange message, the se Upon receiving the ClientKeyExchange message, the se
rver process it as follows. rver process is as follows.
</t> </t>
<t> <ol indent="adaptive" spacing="normal" start="1" type="1" pn="sectio
1. Checks the following three conditions. If either n-4.2.4.1-5">
of these checks fails, then the server MUST abort the handshake with an alert. <li pn="section-4.2.4.1-5.1" derivedCounter="1.">
<list style="symbols"> <t indent="0" pn="section-4.2.4.1-5.1.1">
<t> The following three conditions are checked. If any of th
Q_eph belongs to the same curve as server pu ese checks fail, then the server <bcp14>MUST</bcp14> abort the handshake with an
blic key Q_s; alert.
</t> </t>
<t> <ul empty="false" spacing="normal" bare="false" indent="3" pn="s
Q_eph is not equal to zero point; ection-4.2.4.1-5.1.2">
</t> <li pn="section-4.2.4.1-5.1.2.1"> Q_eph belongs to the same cu
<t> rve as server public key Q_s;
q_s * Q_eph is equal to zero point. </li>
</t> <li pn="section-4.2.4.1-5.1.2.2"> Q_eph is not equal to zero p
</list> oint;
</t> </li>
<t> <li pn="section-4.2.4.1-5.1.2.3"> q_s * Q_eph is equal to zero
2. Generates export keys (K_EXP_MAC and K_EXP_ENC) u point.
sing the KEG algorithm defined in <xref target="KEG"/>: </li>
<list style="empty"> </ul>
<t> </li>
H = HASH(r_c | r_s); <li pn="section-4.2.4.1-5.2" derivedCounter="2.">
</t> <t indent="0" pn="section-4.2.4.1-5.2.1">
<t> The export keys (K_EXP_MAC and K_EXP_ENC) are genera
K_EXP_MAC | K_EXP_ENC = KEG(d_s, Q_eph, H). ted using the KEG algorithm defined in <xref target="KEG" format="default" secti
</t> onFormat="of" derivedContent="Section 8.3.1"/>:
</list> </t>
</t> <sourcecode name="" type="" markers="false" pn="section-4.2.4.1-
<t> 5.2.2">
3. Extracts the premaster secret PS from the export H = HASH(r_c | r_s);
representation PSExp using the KImp15 algorithm defined in <xref target ="KExpIm
p15"/>: K_EXP_MAC | K_EXP_ENC = KEG(d_s, Q_eph, H).
<list style="empty"> </sourcecode>
<t> </li>
IV = H[25..24 + n / 2]; <li pn="section-4.2.4.1-5.3" derivedCounter="3.">
</t> <t indent="0" pn="section-4.2.4.1-5.3.1">
<t> The preliminary secret PS is extracted from the export repres
PS = KImp15(PSExp, K_EXP_MAC, K_EXP_ENC, IV) entation PSExp using the KImp15 algorithm defined in <xref target="KExpImp15" fo
. rmat="default" sectionFormat="of" derivedContent="Section 8.2.1"/>:
</t> </t>
</list> <sourcecode name="" type="" markers="false" pn="section-4.2.4.1-
</t> 5.3.2">
</section> IV = H[25..24 + n / 2];
<section anchor ="CNTkeygen" title = "CNT_IMIT">
<t> PS = KImp15(PSExp, K_EXP_MAC, K_EXP_ENC, IV).
In case of the CNT_IMIT cipher suite the body of the </sourcecode>
ClientKeyExchange message consists of a TLSGostKeyTransportBlob structure that </li>
is defined bellow. </ol>
</t> </section>
<t> <section anchor="CNTkeygen" numbered="true" toc="include" removeInRFC=
"false" pn="section-4.2.4.2">
<name slugifiedName="name-cnt_imit-2">CNT_IMIT</name>
<t indent="0" pn="section-4.2.4.2-1">
In the CNT_IMIT cipher suite, the body of the Client
KeyExchange message consists of a TLSGostKeyTransportBlob structure that is defi
ned below.
</t>
<t indent="0" pn="section-4.2.4.2-2">
The client generates the ClientKeyExchange message i n accordance with the following steps: The client generates the ClientKeyExchange message i n accordance with the following steps:
</t> </t>
<t> <ol indent="adaptive" spacing="normal" start="1" type="1" pn="sectio
1. Generates the ephemeral key pair (Q_eph, d_eph), n-4.2.4.2-3">
where: <li pn="section-4.2.4.2-3.1" derivedCounter="1.">
<list style="empty"> <t indent="0" pn="section-4.2.4.2-3.1.1">
<t> The ephemeral key pair (Q_eph, d_eph) is generated, where:
d_eph is chosen from {1, ... , q_s - 1} at r </t>
andom; <sourcecode name="" type="" markers="false" pn="section-4.2.4.2-
</t> 3.1.2">
<t> d_eph is chosen from {1, ... , q_s - 1} at random;
Q_eph = d_eph * P_s.
</t> Q_eph = d_eph * P_s.
</list> </sourcecode>
</t> </li>
<t> <li pn="section-4.2.4.2-3.2" derivedCounter="2.">
2. Generates the premaster secret PS, where PS is ch The preliminary secret PS is generated, where PS is chosen from B_32
osen from B_32 at random. at random.
</t> </li>
<t> <li pn="section-4.2.4.2-3.3" derivedCounter="3.">
3. Generates export key (K_EXP) using the KEG_28147 <t indent="0" pn="section-4.2.4.2-3.3.1">
algorithm defined in <xref target ="KEG_28147"/>: The export key (K_EXP) is generated using the KEG_28147 algorithm defi
<list style="bullets"> ned in <xref target="KEG_28147" format="default" sectionFormat="of" derivedConte
<t> nt="Section 8.3.2"/>:
H = HASH(r_c | r_s); </t>
</t> <sourcecode name="" type="" markers="false" pn="section-4.2.4.2-
<t> 3.3.2">
K_EXP = KEG_28147(d_eph, Q_s, H). H = HASH(r_c | r_s);
</t>
</list> K_EXP = KEG_28147(d_eph, Q_s, H).
</t> </sourcecode>
<t> </li>
4. Generates an export representation PSExp of the p <li pn="section-4.2.4.2-3.4" derivedCounter="4.">
remaster secret PS using the KExp28147 algorithm defined in <xref target ="KExpI <t indent="0" pn="section-4.2.4.2-3.4.1">
mp28147"/>: An export representation PSExp of the preliminary secret PS
<list style="empty"> using the KExp28147 algorithm defined in <xref target="KExpImp28147" format="def
<t> ault" sectionFormat="of" derivedContent="Section 8.2.2"/> is generated:
PSExp = IV | CEK_ENC | CEK_MAC = KExp28147(P </t>
S, K_EXP, H[1..8]). <sourcecode name="" type="" markers="false" pn="section-4.2.4.2-
</t> 3.4.2">
</list> PSExp = IV | CEK_ENC | CEK_MAC = KExp28147(PS, K_EXP, H[1..8]).
</t> </sourcecode>
<t> </li>
5. Generates the ClientKeyExchange message using the <li pn="section-4.2.4.2-3.5" derivedCounter="5.">
TLSGostKeyTransportBlob structure that is defined as follows: <t indent="0" pn="section-4.2.4.2-3.5.1">
</t> The ClientKeyExchange message is generated using the
<t> TLSGostKeyTransportBlob structure that is defined as follows:
<figure> </t>
<artwork> <sourcecode name="" type="asn.1" markers="false" pn="section-4.2
<![CDATA[ .4.2-3.5.2">
TLSGostKeyTransportBlob ::= SEQUENCE { TLSGostKeyTransportBlob ::= SEQUENCE {
keyBlob GostR3410-KeyTransport, keyBlob GostR3410-KeyTransport
} }
GostR3410-KeyTransport ::= SEQUENCE { GostR3410-KeyTransport ::= SEQUENCE {
sessionEncryptedKey Gost28147-89-EncryptedKey, sessionEncryptedKey Gost28147-89-EncryptedKey,
transportParameters [0] IMPLICIT GostR3410-TransportParameters transportParameters [0] IMPLICIT GostR3410-
OPTIONAL TransportParameters OPTIONAL
} }
Gost28147-89-EncryptedKey ::= SEQUENCE { Gost28147-89-EncryptedKey ::= SEQUENCE {
encryptedKey Gost28147-89-Key, encryptedKey Gost28147-89-Key,
maskKey [0] IMPLICIT Gost28147-89-Key OPTIONAL, maskKey [0] IMPLICIT Gost28147-89-Key OPTIONAL,
macKey Gost28147-89-MAC macKey Gost28147-89-MAC
} }
GostR3410-TransportParameters ::= SEQUENCE { GostR3410-TransportParameters ::= SEQUENCE {
encryptionParamSet OBJECT IDENTIFIER, encryptionParamSet OBJECT IDENTIFIER,
ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL, ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo
OPTIONAL,
ukm OCTET STRING ukm OCTET STRING
} }
]]> </sourcecode>
</artwork> <t indent="0" pn="section-4.2.4.2-3.5.3">
</figure> where GostR3410-KeyTransport, Gost28147-89-Encrypted
</t> Key, and GostR3410-TransportParameters are defined according to <xref target="RF
<t> C4490" section="4.2.1" sectionFormat="of" format="default" derivedLink="https://
where GostR3410-KeyTransport, Gost28147-89-Encrypted rfc-editor.org/rfc/rfc4490#section-4.2.1" derivedContent="RFC4490"/>.
Key and GostR3410-TransportParameters are defined according to Section 4.2.1 of </t>
<xref target="RFC4490"/>. </li>
</t> </ol>
<t> <t indent="0" pn="section-4.2.4.2-4">
In the context of this document the GostR3410-KeyTra In the context of this document, the GostR3410-KeyTr
nsport.transportParameters field is always used, the Gost28147-89-EncryptedKey.m ansport.transportParameters field is always used, the Gost28147-89-EncryptedKey.
askKey field is omitted, maskKey field is omitted, and
the GostR3410-KeyTransport.transportParameters.ephem eralPublicKey field is always used. the GostR3410-KeyTransport.transportParameters.ephem eralPublicKey field is always used.
</t> </t>
<t> <t indent="0" pn="section-4.2.4.2-5">
The Gost28147-89-EncryptedKey.encryptedKey field con tains the CEK_ENC value, the Gost28147-89-EncryptedKey.macKey field contains the The Gost28147-89-EncryptedKey.encryptedKey field con tains the CEK_ENC value, the Gost28147-89-EncryptedKey.macKey field contains the
CEK_MAC value, and GostR3410-TransportParameters.ukm CEK_MAC value, and the GostR3410-TransportParameters
field contains the IV value. .ukm field contains the initialization vector (IV) value.
</t> </t>
<t> <t indent="0" pn="section-4.2.4.2-6">
The keyBlob.transportParameters.ephemeralPublicKey f ield contains the client ephemeral public key Q_eph. The encryptionParamSet The keyBlob.transportParameters.ephemeralPublicKey f ield contains the client ephemeral public key Q_eph. The encryptionParamSet
contains value 1.2.643.7.1.2.5.1.1 that corresponds contains the value 1.2.643.7.1.2.5.1.1, which corres
to the id-tc26-gost-28147-param-Z parameters set defined in <xref target="RFC783 ponds to the id-tc26-gost-28147-param-Z parameters set defined in <xref target="
6"/>. RFC7836" format="default" sectionFormat="of" derivedContent="RFC7836"/>.
</t> </t>
<t indent="0" pn="section-4.2.4.2-7">
Upon receiving the ClientKeyExchange message, the se
rver process is as follows.
</t>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="sectio
n-4.2.4.2-8">
<li pn="section-4.2.4.2-8.1" derivedCounter="1.">
<t indent="0" pn="section-4.2.4.2-8.1.1">
The following three conditions are checked. If either
of these checks fails, then the server <bcp14>MUST</bcp14> abort the handshake
with an alert.
</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="s
ection-4.2.4.2-8.1.2">
<li pn="section-4.2.4.2-8.1.2.1">
<t>
Upon receiving the ClientKeyExchange message, the se
rver process it as follows.
</t>
<t>
1. Checks the following three conditions. If either
of these checks fails, then the server MUST abort the handshake with an alert.
<list style="symbols">
<t>
Q_eph belongs to the same curve as server pu blic key Q_s; Q_eph belongs to the same curve as server pu blic key Q_s;
</t> </li>
<t> <li pn="section-4.2.4.2-8.1.2.2">
Q_eph is not equal to zero point; Q_eph is not equal to zero point;
</t> </li>
<t> <li pn="section-4.2.4.2-8.1.2.3">
q_s * Q_eph is equal to zero point; q_s * Q_eph is equal to zero point.
</t> </li>
</list> </ul>
</t> </li>
<t> <li pn="section-4.2.4.2-8.2" derivedCounter="2.">
2. Generates export key (K_EXP) using the KEG_28147 <t indent="0" pn="section-4.2.4.2-8.2.1">
algorithm defined in <xref target ="KEG_28147"/>: The export key (K_EXP) is generated using the KEG_28147
<list style="bullets"> algorithm defined in <xref target="KEG_28147" format="default" sectionFormat="of
<t> " derivedContent="Section 8.3.2"/>:
H = HASH(r_c | r_s); </t>
</t> <sourcecode name="" type="" markers="false" pn="section-4.2.4.2-
<t> 8.2.2">
K_EXP = KEG_28147(d_s, Q_eph, H). H = HASH(r_c | r_s);
</t>
</list>
</t>
<t>
3. Extracts the premaster secret PS from the export
representation PSExp using the KImp28147 algorithm defined in <xref target ="KEx
pImp28147"/>:
<list style="empty">
<t>
PS = KImp28147(PSExp, K_EXP, H[1..8]).
</t>
</list>
</t>
</section>
</section>
<section anchor ="CertVer" title="CertificateVerify"> K_EXP = KEG_28147(d_s, Q_eph, H).
<t> </sourcecode>
Client generates the value sgn as follows: </li>
</t> <li pn="section-4.2.4.2-8.3" derivedCounter="3.">
<t> <t indent="0" pn="section-4.2.4.2-8.3.1">
<figure> The preliminary secret PS is extracted from the export represent
<artwork> ation PSExp using the KImp28147 algorithm defined in <xref target="KExpImp28147"
<![CDATA[ format="default" sectionFormat="of" derivedContent="Section 8.2.2"/>:
</t>
<sourcecode name="" type="" markers="false" pn="section-4.2.4.2-
8.3.2">
PS = KImp28147(PSExp, K_EXP, H[1..8]).
</sourcecode>
</li>
</ol>
</section>
</section>
<section anchor="CertVer" numbered="true" toc="include" removeInRFC="fal
se" pn="section-4.2.5">
<name slugifiedName="name-certificateverify">CertificateVerify</name>
<t indent="0" pn="section-4.2.5-1">
The client generates the value sgn as follows:
</t>
<sourcecode name="" type="" markers="false" pn="section-4.2.5-2">
sgn = SIGN_{d_c}(handshake_messages) = str_l(r) | str_l(s) sgn = SIGN_{d_c}(handshake_messages) = str_l(r) | str_l(s)
]]> </sourcecode>
</artwork> <t indent="0" pn="section-4.2.5-3">
</figure> where SIGN_{d_c} is the GOST R 34.10-2012 <xref target="RFC7091" format
</t> ="default" sectionFormat="of" derivedContent="RFC7091"/> signature algorithm, d_
<t> c is a client long-term private key that corresponds to the client long-term pub
where SIGN_{d_c} is the GOST R 34.10-2012 <xref target=" lic key Q_c from the client's certificate, l = 32 for the gostr34102012_256 valu
RFC7091"/> signature algorithm, d_c is a client e of the SignatureAndHashAlgorithm field, and l = 64 for the gostr34102012_512 v
long-term private key that corresponds to the client lon alue of the SignatureAndHashAlgorithm field.
g-term public key Q_c from the client's certificate, </t>
l = 32 for gostr34102012_256 value of the SignatureAndHa <t indent="0" pn="section-4.2.5-4">
shAlgorithm field and l = 64 for gostr34102012_512 value of the SignatureAndHash Here, "handshake_messages" refers to all handshake messa
Algorithm field. ges sent or
</t> received, starting at ClientHello and up to CertificateV
<t> erify without
Here handshake_messages refers to all handshake messages the last message; it includes the type and length fields
sent or of the handshake messages.
received, starting at ClientHello and up to CertificateV </t>
erify, but not including <t indent="0" pn="section-4.2.5-5">
the last message, including the type and length fields o The TLS CertificateVerify message is specified as follow
f the handshake messages. s:
</t> </t>
<t> <sourcecode name="" type="asn.1" markers="false" pn="section-4.2.5-6">
The TLS CertificateVerify message is specified as follow
s.
</t>
<t>
<figure>
<artwork>
<![CDATA[
struct { struct {
SignatureAndHashAlgorithm algorithm; SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1&gt;; opaque signature<0..2^16-1&gt;;
} CertificateVerify; } CertificateVerify;
]]> </sourcecode>
</artwork> <t indent="0" pn="section-4.2.5-7">
</figure> where the SignatureAndHashAlgorithm structure is specifi
</t> ed in <xref target="SAR" format="default" sectionFormat="of" derivedContent="Sec
<t> tion 5"/>, and the CertificateVerify.signature field contains the sgn value.
where SignatureAndHashAlgorithm structure is specified i </t>
n <xref target="SAR"/> and CertificateVerify.signature field contains sgn value. </section>
</t> <section numbered="true" toc="include" removeInRFC="false" pn="section-4
</section> .2.6">
<name slugifiedName="name-finished">Finished</name>
<section title="Finished"> <t indent="0" pn="section-4.2.6-1">
<t> The TLS Finished message is generated in
The TLS Finished message is generated in accordance with accordance with <xref target="RFC5246" section="7.4.9" s
Section 7.4.9 of <xref target="RFC5246"/>. ectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc52
</t> 46#section-7.4.9" derivedContent="RFC5246"/>.
<t> </t>
<t indent="0" pn="section-4.2.6-2">
The verify_data_length value is equal to 32 for the CTR_ OMAC cipher suites and is equal to 12 for the CNT_IMIT cipher suite. The verify_data_length value is equal to 32 for the CTR_ OMAC cipher suites and is equal to 12 for the CNT_IMIT cipher suite.
The PRF function is defined in <xref target="PRFHASH"/>. The pseudorandom function (PRF) is defined in <xref targ
</t> et="PRFHASH" format="default" sectionFormat="of" derivedContent="Section 4.3.4"/
</section> >.
</section> </t>
</section>
<section title="Cryptographic Algorithms"> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4.3
<section anchor="BlockCipher" title="Block Cipher"> ">
<t> <name slugifiedName="name-cryptographic-algorithms">Cryptographic Algori
The cipher suite TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR thms</name>
_OMAC MUST use Kuznyechik <xref target="RFC7801"/> <section anchor="BlockCipher" numbered="true" toc="include" removeInRFC=
"false" pn="section-4.3.1">
<name slugifiedName="name-block-cipher">Block Cipher</name>
<t indent="0" pn="section-4.3.1-1">
The cipher suite TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR
_OMAC <bcp14>MUST</bcp14> use Kuznyechik <xref target="RFC7801" format="default"
sectionFormat="of" derivedContent="RFC7801"/>
as a base block cipher for the encryption and MAC algori thm. as a base block cipher for the encryption and MAC algori thm.
The block length n is 16 bytes and the key length k is 3 The block length n is 16 bytes, and the key length k is
2 bytes. 32 bytes.
</t> </t>
<t> <t indent="0" pn="section-4.3.1-2">
The cipher suite TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC The cipher suite TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC
MUST use Magma <xref target="RFC8891"/> <bcp14>MUST</bcp14> use Magma <xref target="RFC8891" format="default" sectionFo
rmat="of" derivedContent="RFC8891"/>
as a base block cipher for the encryption and MAC algori thm. as a base block cipher for the encryption and MAC algori thm.
The block length n is 8 bytes and the key length k is 32 The block length n is 8 bytes, and the key length k is 3
bytes. 2 bytes.
</t> </t>
<t> <t indent="0" pn="section-4.3.1-3">
The cipher suite TLS_GOSTR341112_256_WITH_28147_CNT_IMIT The cipher suite TLS_GOSTR341112_256_WITH_28147_CNT_IMIT
MUST use GOST 28147-89 as a base block cipher <xref target ="RFC5830"/> <bcp14>MUST</bcp14> use GOST 28147-89 as a base block cipher <xref target="RFC5
with the set of parameters id-tc26-gost-28147-param-Z de 830" format="default" sectionFormat="of" derivedContent="RFC5830"/>
fined in <xref target="RFC7836"/>. with the set of parameters id-tc26-gost-28147-param-Z de
The block length n is 8 bytes and the key length k is 32 fined in <xref target="RFC7836" format="default" sectionFormat="of" derivedConte
bytes. nt="RFC7836"/>.
</t> The block length n is 8 bytes, and the key length k is 3
</section> 2 bytes.
<section anchor="MAC" title="MAC algorithm"> </t>
<t> </section>
The CTR_OMAC cipher suites use the OMAC message authenti <section anchor="MAC" numbered="true" toc="include" removeInRFC="false"
cation code construction defined in <xref target="GOST3413-2015"/>, pn="section-4.3.2">
which can be considered as the CMAC mode defined in <xre <name slugifiedName="name-mac-algorithm">MAC Algorithm</name>
f target="CMAC"/> where Kuznyechik or Magma block cipher (see <xref target="Bloc <t indent="0" pn="section-4.3.2-1">
kCipher"/>) are used instead of AES block cipher The CTR_OMAC cipher suites use the One-Key MAC (OMAC) constructi
(see <xref target="IK2003"/> for more detail) as the MAC on defined in <xref target="GOST3413-2015" format="default" sectionFormat="of" d
function. The resulting MAC length is equal to the block length and the MAC key erivedContent="GOST3413-2015"/>,
length is 32 bytes. which is the same as the Cipher-Based MAC (CMAC) mode defined in
<xref target="CMAC" format="default" sectionFormat="of" derivedContent="CMAC"/>
where the Kuznyechik or Magma block cipher (see <xref target="BlockCipher" form
at="default" sectionFormat="of" derivedContent="Section 4.3.1"/>) is used instea
d of the AES block cipher
(see <xref target="IK2003" format="default" sectionFormat="of" d
erivedContent="IK2003"/> for more detail) as the MAC function. The resulting MAC
length is equal to the block length, and the MAC key length is 32 bytes.
</t> </t>
<t> <t indent="0" pn="section-4.3.2-2">
The CNT_IMIT cipher suite uses the message authenticatio The CNT_IMIT cipher suite uses the MAC function gostIMIT28147 de
n code function gostIMIT28147 defined in <xref target ="IMIT"/> with the initial fined in <xref target="IMIT" format="default" sectionFormat="of" derivedContent=
ization vector IV = IV0, where IV0 in B_8 is a string of all zeros, "Section 8.4"/> with the initialization vector IV = IV0, where IV0 in B_8 is a s
with the CryptoPro Key Meshing algorithm defined in <xre tring of all zeros,
f target =" RFC4357"/>. The resulting MAC length is 4 bytes and the MAC key leng with the CryptoPro Key Meshing algorithm defined in <xref target
th is 32 bytes. ="RFC4357" format="default" sectionFormat="of" derivedContent="RFC4357"/>. The r
</t> esulting MAC length is 4 bytes, and the MAC key length is 32 bytes.
</section> </t>
<section anchor="EncryptionAlgorithm" title="Encryption algorit </section>
hm"> <section anchor="EncryptionAlgorithm" numbered="true" toc="include" remo
<t> veInRFC="false" pn="section-4.3.3">
The CTR_OMAC cipher suites use the block cipher in CTR-A <name slugifiedName="name-encryption-algorithm">Encryption Algorithm</
CPKM encryption mode defined in <xref target="RFC8645"/> as the ENC function. name>
The section size N is 4 KB for TLS_GOSTR341112_256_WITH_ <t indent="0" pn="section-4.3.3-1">
KUZNYECHIK_CTR_OMAC cipher suite The CTR_OMAC cipher suites use the block cipher in the C
and 1 KB for TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC cip TR-ACPKM encryption mode defined in <xref target="RFC8645" format="default" sect
her suite. ionFormat="of" derivedContent="RFC8645"/> as the ENC function.
</t> The section size N is 4 KB for the TLS_GOSTR341112_256_W
<t> ITH_KUZNYECHIK_CTR_OMAC cipher suite
and 1 KB for the TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC
cipher suite.
</t>
<t indent="0" pn="section-4.3.3-2">
The CNT_IMIT cipher suite uses the block cipher in count er encryption mode (CNT) The CNT_IMIT cipher suite uses the block cipher in count er encryption mode (CNT)
defined in Section 6 of <xref target="RFC5830"/> with th defined in <xref target="RFC5830" section="6" sectionFor
e CryptoPro Key Meshing mat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5830#sectio
algorithm defined in <xref target =" RFC4357"/> as the E n-6" derivedContent="RFC5830"/>, with the CryptoPro key meshing
NC function. algorithm defined in <xref target="RFC4357" format="defa
</t> ult" sectionFormat="of" derivedContent="RFC4357"/> as the ENC function.
<t> </t>
<t indent="0" pn="section-4.3.3-3">
Note that the counter modes used in cipher suites descri bed in this document act as stream ciphers. Note that the counter modes used in cipher suites descri bed in this document act as stream ciphers.
</t> </t>
</section>
<section anchor ="PRFHASH" title="PRF and HASH algorithms">
<t>
The pseudorandom function (PRF) for all the cipher suite
s defined in this document is the PRF_TLS_GOSTR3411_2012_256 function defined in
<xref target="RFC7836"/>.
</t>
<t>
The hash function HASH for all the cipher suites defined
in this document is the GOST R 34.11-2012 <xref target =" RFC6986"/> hash algor
ithm with 32-byte (256-bit) hash code.
</t>
</section>
<section title="SNMAX parameter">
<t>
The SNMAX parameter defines the maximal value of the seque
nce number seqnum during one TLS 1.2 connection and is defined as follows:
</t>
<t>
<figure>
<artwork>
<![CDATA[
+---------------------------------------------+--------------------+
| CipherSuites | SNMAX |
+---------------------------------------------+--------------------+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC | SNMAX = 2^64 - 1 |
|TLS_GOSTR341112_256_WITH_28147_CNT_IMIT | |
+---------------------------------------------+--------------------+
|TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC | SNMAX = 2^32 - 1 |
+---------------------------------------------+--------------------+
Table 1
]]>
</artwork>
</figure>
</t>
</section>
</section>
</section> </section>
<section anchor="SAR" title="New Values for the SignatureAlgorithm Regi <section anchor="PRFHASH" numbered="true" toc="include" removeInRFC="fal
stry"> se" pn="section-4.3.4">
<t> <name slugifiedName="name-prf-and-hash-algorithms">PRF and HASH Algori
thms</name>
<t indent="0" pn="section-4.3.4-1">
The PRF for all the cipher suites defined in this docume
nt is the PRF_TLS_GOSTR3411_2012_256 function defined in <xref target="RFC7836"
format="default" sectionFormat="of" derivedContent="RFC7836"/>.
</t>
<t indent="0" pn="section-4.3.4-2">
The hash function HASH for all the cipher suites defined
in this document is the GOST R 34.11-2012 <xref target="RFC6986" format="defaul
t" sectionFormat="of" derivedContent="RFC6986"/> hash algorithm with a 32-byte (
256-bit) hash code.
</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4
.3.5">
<name slugifiedName="name-snmax-parameter">SNMAX Parameter</name>
<t indent="0" pn="section-4.3.5-1">
The SNMAX parameter defines the maximal value of the seqnu
m sequence number during one TLS 1.2 connection and is defined as follows:
</t>
<table align="center" pn="table-1">
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Cipher Suites</th>
<th align="left" colspan="1" rowspan="1">SNMAX</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">
<ul empty="true" bare="true" spacing="compact" indent="3" pn="
section-4.3.5-2.2.1.1.1">
<li pn="section-4.3.5-2.2.1.1.1.1">TLS_GOSTR341112_256_WITH_
KUZNYECHIK_CTR_OMAC</li>
<li pn="section-4.3.5-2.2.1.1.1.2">TLS_GOSTR341112_256_WITH_
28147_CNT_IMIT</li>
</ul>
</td>
<td align="left" colspan="1" rowspan="1">SNMAX = 2<sup>64</sup>
- 1</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">TLS_GOSTR341112_256_WIT
H_MAGMA_CTR_OMAC</td>
<td align="left" colspan="1" rowspan="1"> SNMAX = 2<sup>32</sup>
- 1</td>
</tr>
</tbody>
</table>
</section>
</section>
</section>
<section anchor="SAR" numbered="true" toc="include" removeInRFC="false" pn="
section-5">
<name slugifiedName="name-new-values-for-the-tls-sign">New Values for the
TLS SignatureAlgorithm Registry</name>
<t indent="0" pn="section-5-1">
The signature/hash algorithm pairs are used to indicate to the s erver/client The signature/hash algorithm pairs are used to indicate to the s erver/client
which algorithms can be used in digital signatures and which algorithms can be used in digital signatures and
are defined by the SignatureAndHashAlgorithm structure (see Sect are defined by the SignatureAndHashAlgorithm structure (see <xre
ion 7.4.1.4.1 of <xref target="RFC5246"/>). f target="RFC5246" section="7.4.1.4.1" sectionFormat="of" format="default" deriv
</t> edLink="https://rfc-editor.org/rfc/rfc5246#section-7.4.1.4.1" derivedContent="RF
<t> C5246"/>).
This document defines new values for the "SignatureAlgorithm Reg </t>
istry" that can be used in the SignatureAndHashAlgorithm.signature field for the <t indent="0" pn="section-5-2">
particular signature/hash algorithm pair: This document defines new values for the "TLS SignatureAlgorithm
</t> " registry that can be used in the SignatureAndHashAlgorithm.signature field for
<t> the particular signature/hash algorithm pair:
<figure> </t>
<artwork> <sourcecode name="" type="asn.1" markers="false" pn="section-5-3">
<![CDATA[
enum { enum {
gostr34102012_256(64), gostr34102012_256(64),
gostr34102012_512(65), gostr34102012_512(65),
} SignatureAlgorithm; } SignatureAlgorithm;
]]> </sourcecode>
</artwork> <t indent="0" pn="section-5-4">
</figure>
</t>
<t>
where the gostr34102012_256 and gostr34102012_512 values corresp ond to where the gostr34102012_256 and gostr34102012_512 values corresp ond to
the GOST R 34.10-2012 <xref target="RFC7091"/> signature algorit the GOST R 34.10-2012 <xref target="RFC7091" format="default" se
hm with 32-byte (256-bit) and 64-byte (512-bit) key length respectively. ctionFormat="of" derivedContent="RFC7091"/> signature algorithm with a 32-byte (
</t> 256-bit) and 64-byte (512-bit) key length, respectively.
<t> </t>
According to <xref target="RFC7091"/> the GOST R 34.10-2012 sign <t indent="0" pn="section-5-5">
ature algorithm with 32-byte (256-bit) or 64-byte (512-bit) key length According to <xref target="RFC7091" format="default" sectionForm
use the GOST R 34.11-2012 <xref target="RFC6986"/> hash algorith at="of" derivedContent="RFC7091"/>, the GOST R 34.10-2012 signature algorithm wi
m with 32-byte (256-bit) or 64-byte (512-bit) hash code respectively th a 32-byte (256-bit) or 64-byte (512-bit) key length
uses the GOST R 34.11-2012 <xref target="RFC6986" format="defaul
t" sectionFormat="of" derivedContent="RFC6986"/> hash algorithm with a 32-byte (
256-bit) or 64-byte (512-bit) hash code, respectively
(the hash algorithm is intrinsic to the signature algorithm). (the hash algorithm is intrinsic to the signature algorithm).
Therefore, if the SignatureAndHashAlgorithm.signature field of a particular hash/signature pair listed in the Signature Algorithms Extension Therefore, if the SignatureAndHashAlgorithm.signature field of a particular hash/signature pair listed in the Signature Algorithms Extension
is equal to the 64 (gostr34102012_256) or 65 (gostr34102012_512) value, is equal to the 64 (gostr34102012_256) or 65 (gostr34102012_512) value,
the SignatureAndHashAlgorithm.hash field of this pair MUST conta the SignatureAndHashAlgorithm.hash field of this pair <bcp14>MUS
in the "Intrinsic" value 8 (see <xref target="RFC8422"/>). T</bcp14> contain the "Intrinsic" value 8 (see <xref target="RFC8422" format="de
</t> fault" sectionFormat="of" derivedContent="RFC8422"/>).
<t> </t>
<t indent="0" pn="section-5-6">
So, to represent gostr34102012_256 and gostr34102012_512 in the signature_algorithms extension, the value shall be (8,64) and (8,65), respective ly. So, to represent gostr34102012_256 and gostr34102012_512 in the signature_algorithms extension, the value shall be (8,64) and (8,65), respective ly.
</t> </t>
</section> </section>
<section anchor="SGR" title="New Values for the Supported Groups Regist <section anchor="SGR" numbered="true" toc="include" removeInRFC="false" pn="
ry"> section-6">
<t> <name slugifiedName="name-new-values-for-the-tls-supp">New Values for the
TLS Supported Groups Registry</name>
<t indent="0" pn="section-6-1">
The Supported Groups Extension indicates the set of elliptic cur ves supported by the client and The Supported Groups Extension indicates the set of elliptic cur ves supported by the client and
is defined in <xref target="RFC8422"/> and <xref target="RFC7919 is defined in <xref target="RFC8422" format="default" sectionFor
"/>. mat="of" derivedContent="RFC8422"/> and <xref target="RFC7919" format="default"
</t> sectionFormat="of" derivedContent="RFC7919"/>.
<t> </t>
This document defines new values for the "Supported Groups" regi <t indent="0" pn="section-6-2">
stry: This document defines new values for the "TLS Supported Groups"
</t> registry:
<t> </t>
<figure> <sourcecode name="" type="asn.1" markers="false" pn="section-6-3">
<artwork>
<![CDATA[
enum { enum {
GC256A(34), GC256B(35), GC256C(36), GC256D(37), GC256A(34), GC256B(35), GC256C(36), GC256D(37),
GC512A(38), GC512B(39), GC512C(40), GC512A(38), GC512B(39), GC512C(40),
} NamedGroup; } NamedGroup;
]]> </sourcecode>
</artwork> <t indent="0" pn="section-6-4">
</figure> where the values correspond to the following curves:
</t> </t>
<table anchor="tab-2" align="center" pn="table-2">
<t> <thead>
Where the values corresponds to the following curves: <tr>
</t> <th align="left" colspan="1" rowspan="1">Description</th>
<t> <th align="left" colspan="1" rowspan="1">Curve Identifier Value</th>
<figure> <th align="left" colspan="1" rowspan="1">Reference</th>
<artwork> </tr>
<![CDATA[ </thead>
+-------------+--------------------------------------+-----------+ <tbody>
| Description | Curve Identifier Value | Reference | <tr>
+-------------+--------------------------------------+-----------+ <td align="left" colspan="1" rowspan="1">GC256A</td>
| GC256A | id-tc26-gost-3410-2012-256-paramSetA | RFC 7836 | <td align="left" colspan="1" rowspan="1">id-tc26-gost-3410-2012-256-
+-------------+--------------------------------------+-----------+ paramSetA</td>
| GC256B |id-GostR3410-2001-CryptoPro-A-ParamSet| RFC 4357 | <td align="left" colspan="1" rowspan="1">
+-------------+--------------------------------------+-----------+ <xref target="RFC7836" format="default" sectionFormat="of" derived
| GC256C |id-GostR3410-2001-CryptoPro-B-ParamSet| RFC 4357 | Content="RFC7836"/> </td>
+-------------+--------------------------------------+-----------+ </tr>
| GC256D |id-GostR3410-2001-CryptoPro-C-ParamSet| RFC 4357 | <tr>
+-------------+--------------------------------------+-----------+ <td align="left" colspan="1" rowspan="1">GC256B</td>
| GC512A | id-tc26-gost-3410-12-512-paramSetA | RFC 7836 | <td align="left" colspan="1" rowspan="1">id-GostR3410-2001-CryptoPro
+-------------+--------------------------------------+-----------+ -A-ParamSet</td>
| GC512B | id-tc26-gost-3410-12-512-paramSetB | RFC 7836 | <td align="left" colspan="1" rowspan="1">
+-------------+--------------------------------------+-----------+ <xref target="RFC4357" format="default" sectionFormat="of" derived
| GC512C | id-tc26-gost-3410-2012-512-paramSetC | RFC 7836 | Content="RFC4357"/></td>
+-------------+--------------------------------------+-----------+ </tr>
Table 2 <tr>
]]> <td align="left" colspan="1" rowspan="1">GC256C</td>
</artwork> <td align="left" colspan="1" rowspan="1">id-GostR3410-2001-CryptoPro
</figure> -B-ParamSet</td>
</t> <td align="left" colspan="1" rowspan="1">
</section> <xref target="RFC4357" format="default" sectionFormat="of" derived
<section anchor="CTIR" title="New Values for the ClientCertificateType Content="RFC4357"/> </td>
Identifiers Registry"> </tr>
<t> <tr>
The ClientCertificateType field of the CertificateRequest messag <td align="left" colspan="1" rowspan="1">GC256D</td>
e contains a list of the types of certificate types that the client may <td align="left" colspan="1" rowspan="1">id-GostR3410-2001-CryptoPro
offer and is defined in Section 7.4.4 of <xref target="RFC5246"/ -C-ParamSet</td>
>. <td align="left" colspan="1" rowspan="1">
</t> <xref target="RFC4357" format="default" sectionFormat="of" derived
<t> Content="RFC4357"/></td>
This document defines new values for the "ClientCertificateType </tr>
Identifiers" registry: <tr>
</t> <td align="left" colspan="1" rowspan="1">GC512A</td>
<t> <td align="left" colspan="1" rowspan="1"> id-tc26-gost-3410-12-512-
<figure> paramSetA</td>
<artwork> <td align="left" colspan="1" rowspan="1">
<![CDATA[ <xref target="RFC7836" format="default" sectionFormat="of" derived
Content="RFC7836"/></td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">GC512B</td>
<td align="left" colspan="1" rowspan="1">id-tc26-gost-3410-12-512-pa
ramSetB</td>
<td align="left" colspan="1" rowspan="1">
<xref target="RFC7836" format="default" sectionFormat="of" derived
Content="RFC7836"/></td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">GC512C</td>
<td align="left" colspan="1" rowspan="1"> id-tc26-gost-3410-2012-512
-paramSetC</td>
<td align="left" colspan="1" rowspan="1">
<xref target="RFC7836" format="default" sectionFormat="of" derived
Content="RFC7836"/></td>
</tr>
</tbody>
</table>
</section>
<section anchor="CTIR" numbered="true" toc="include" removeInRFC="false" pn=
"section-7">
<name slugifiedName="name-new-values-for-the-tls-clie">New Values for the
TLS ClientCertificateType Identifiers Registry</name>
<t indent="0" pn="section-7-1">
The ClientCertificateType field of the CertificateRequest messag
e contains a list of certificate types that the client may
offer and is defined in <xref target="RFC5246" section="7.4.4" s
ectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc52
46#section-7.4.4" derivedContent="RFC5246"/>.
</t>
<t indent="0" pn="section-7-2">
This document defines new values for the "TLS ClientCertificateT
ype Identifiers" registry:
</t>
<sourcecode name="" type="asn.1" markers="false" pn="section-7-3">
enum { enum {
gost_sign256(67), gost_sign256(67),
gost_sign512(68), gost_sign512(68),
} ClientCertificateType; } ClientCertificateType;
]]> </sourcecode>
</artwork> <t indent="0" pn="section-7-4">
</figure> To use the gost_sign256 or gost_sign512 authentication mechanism
</t> , the client <bcp14>MUST</bcp14> possess a
<t> certificate containing a GOST R 34.10-2012-capable public key th
To use the gost_sign256 or gost_sign512 authentication mechanism at corresponds to the 32-byte (256-bit) or 64-byte (512-bit) signature key, resp
, the client MUST possess a ectively.
certificate containing a GOST R 34.10-2012-capable public key th </t>
at corresponds to the 32-byte (256-bit) or 64-byte (512-bit) signature key respe <t indent="0" pn="section-7-5">
ctively.
</t>
<t>
The client proves possession of the private key corresponding to the The client proves possession of the private key corresponding to the
certified key by including a signature in the CertificateVerify certified key by including a signature in the CertificateVerify
message as described in <xref target="CertVer"/>. message as described in <xref target="CertVer" format="default"
</t> sectionFormat="of" derivedContent="Section 4.2.5"/>.
</section> </t>
</section>
<section anchor ="UA" title="Additional Algorithms"> <section anchor="UA" numbered="true" toc="include" removeInRFC="false" pn="s
<t> ection-8">
<name slugifiedName="name-additional-algorithms">Additional Algorithms</na
me>
<t indent="0" pn="section-8-1">
The cipher suites specified in this document rely on some additi onal algorithms, specified below; the use of these algorithms is not confined to the use in TLS specified in this document. The cipher suites specified in this document rely on some additi onal algorithms, specified below; the use of these algorithms is not confined to the use in TLS specified in this document.
</t> </t>
<section anchor ="TLSTREE" title ="TLSTREE"> <section anchor="TLSTREE" numbered="true" toc="include" removeInRFC="false
<t> " pn="section-8.1">
<name slugifiedName="name-tlstree">TLSTREE</name>
<t indent="0" pn="section-8.1-1">
The TLSTREE function is defined as follows: The TLSTREE function is defined as follows:
<list style = "empty"> </t>
<t> <sourcecode name="" type="" markers="false" pn="section-8.1-2">
TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8 TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8(i &amp; C_1)),
(i &amp; C_1)), STR_8(i &amp; C_2)), STR_8(i &amp; C_3)), STR_8(i &amp; C_2)), STR_8(i &amp; C_3)),
</t> </sourcecode>
</list> <t indent="0" pn="section-8.1-3">
</t>
<t>
where where
<list style = "symbols"> </t>
<t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8
K_root in B_32; .1-4">
</t> <li pn="section-8.1-4.1"> K_root in B_32;
<t> </li>
i in {0, 1, ... , 2^64 - 1}; <li pn="section-8.1-4.2"> i in {0, 1, ... , 2<sup>64</sup> - 1};
</t> </li>
<t> <li pn="section-8.1-4.3"> C_1, C_2, C_3 are constants defined by the p
C_1, C_2, C_3 are constants defined by the particula articular cipher suite (see <xref target="TreeParam" format="default" sectionFor
r cipher suite (see <xref target="TreeParam"/>); mat="of" derivedContent="Section 8.1.1"/>);
</t> </li>
<t> <li pn="section-8.1-4.4">
<t indent="0" pn="section-8.1-4.4.1">
KDF_j(K, D), j = 1, 2, 3, K in B_32, KDF_j(K, D), j = 1, 2, 3, K in B_32,
D in B_8, is the key derivation function based on th e KDF_GOSTR3411_2012_256 D in B_8, is the key derivation function based on th e KDF_GOSTR3411_2012_256
function defined in <xref target="RFC7836"/>:<vspace function defined in <xref target="RFC7836" format="default" sectionF
/> ormat="of" derivedContent="RFC7836"/>:</t>
<vspace/> <sourcecode name="" type="" markers="false" pn="section-8.1-4.4.2">
KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D) KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D);
;<vspace/>
KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D)
;<vspace/>
KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D)
.
<vspace/>
</t>
</list>
</t>
<section anchor="TreeParam" title="Key Tree Parameters">
<t>
The CTR_OMAC cipher suites use the TLSTREE function for
the re-keying approach. The constants for it
are defined as in the table below.
</t>
<t>
<figure>
<artwork>
<![CDATA[
+--------------------------------------------+----------------------+
| CipherSuites | C_1, C_2, C_3 |
+--------------------------------------------+----------------------+
|TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC|C_1=0xFFFFFFFF00000000|
| |C_2=0xFFFFFFFFFFF80000|
| |C_3=0xFFFFFFFFFFFFFFC0|
+--------------------------------------------+----------------------+
|TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC |C_1=0xFFFFFFC000000000|
| |C_2=0xFFFFFFFFFE000000|
| |C_3=0xFFFFFFFFFFFFF000|
+--------------------------------------------+----------------------+
Table 3
]]>
</artwork>
</figure>
</t>
</section>
</section>
<section anchor ="KEXP" title="Key export and key import algorithms" KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D); and
>
<section anchor ="KExpImp15" title="KExp15 and KImp15 Algorithms KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D).
"> </sourcecode>
<t> </li>
</ul>
<section anchor="TreeParam" numbered="true" toc="include" removeInRFC="f
alse" pn="section-8.1.1">
<name slugifiedName="name-key-tree-parameters">Key Tree Parameters</na
me>
<t indent="0" pn="section-8.1.1-1">
The CTR_OMAC cipher suites use the TLSTREE function for
the rekeying approach. The constants for it
are defined as in the table below.
</t>
<table align="center" pn="table-3">
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Cipher Suites</th>
<th align="left" colspan="1" rowspan="1">C_1, C_2, C_3</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">TLS_GOSTR341112_256_WIT
H_KUZNYECHIK_CTR_OMAC</td>
<td align="left" colspan="1" rowspan="1">
<ul empty="true" bare="true" spacing="compact" indent="3" pn="
section-8.1.1-2.2.1.2.1">
<li pn="section-8.1.1-2.2.1.2.1.1">C_1=0xFFFFFFFF00000000</l
i>
<li pn="section-8.1.1-2.2.1.2.1.2">C_2=0xFFFFFFFFFFF80000</l
i>
<li pn="section-8.1.1-2.2.1.2.1.3">C_3=0xFFFFFFFFFFFFFFC0</l
i>
</ul>
</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">TLS_GOSTR341112_256_WIT
H_MAGMA_CTR_OMAC</td>
<td align="left" colspan="1" rowspan="1">
<ul empty="true" bare="true" spacing="compact" indent="3" pn="
section-8.1.1-2.2.2.2.1">
<li pn="section-8.1.1-2.2.2.2.1.1">C_1=0xFFFFFFC000000000</l
i>
<li pn="section-8.1.1-2.2.2.2.1.2">C_2=0xFFFFFFFFFE000000</l
i>
<li pn="section-8.1.1-2.2.2.2.1.3">C_3=0xFFFFFFFFFFFFF000</l
i>
</ul>
</td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="KEXP" numbered="true" toc="include" removeInRFC="false" p
n="section-8.2">
<name slugifiedName="name-key-export-and-key-import-a">Key Export and Ke
y Import Algorithms</name>
<section anchor="KExpImp15" numbered="true" toc="include" removeInRFC="f
alse" pn="section-8.2.1">
<name slugifiedName="name-kexp15-and-kimp15-algorithm">KExp15 and KImp
15 Algorithms</name>
<t indent="0" pn="section-8.2.1-1">
Algorithms KExp15 and KImp15 use the block cipher determined by the particular cipher suite. Algorithms KExp15 and KImp15 use the block cipher determined by the particular cipher suite.
</t> </t>
<t> <t indent="0" pn="section-8.2.1-2">
The KExp15 key export algorithm is defined as follows. The KExp15 key export algorithm is defined as follows:
</t> </t>
<t> <sourcecode type="pseudocode" markers="false" pn="section-8.2.1-3">
<figure>
<artwork>
<![CDATA[
+------------------------------------------------------------+ +------------------------------------------------------------+
| KExp15(S, K_Exp_MAC, K_Exp_ENC, IV) | | KExp15(S, K_Exp_MAC, K_Exp_ENC, IV) |
|------------------------------------------------------------| |------------------------------------------------------------|
| Input: | | Input: |
| - secret S to be exported, S in B*, | | - secret S to be exported, S in B*, |
| - key K_Exp_MAC in B_k, | | - key K_Exp_MAC in B_k, |
| - key K_Exp_ENC in B_k, | | - key K_Exp_ENC in B_k, |
| - IV in B_{n/2} | | - IV in B_{n/2} |
| Output: | | Output: |
| - export representation SExp in B_{L(S)+n} | | - export representation SExp in B_{L(S)+n} |
|------------------------------------------------------------| |------------------------------------------------------------|
| 1. CEK_MAC = OMAC(K_Exp_MAC, IV | S), CEK_MAC in B_n | | 1. CEK_MAC = OMAC(K_Exp_MAC, IV | S), CEK_MAC in B_n |
| 2. SExp = CTR-Encrypt(K_Exp_ENC, IV, S | CEK_MAC) | | 2. SExp = CTR-Encrypt(K_Exp_ENC, IV, S | CEK_MAC) |
| 3. return SExp | | 3. return SExp |
+------------------------------------------------------------+ +------------------------------------------------------------+
]]> </sourcecode>
</artwork> <t indent="0" pn="section-8.2.1-4">
</figure> where the OMAC function is defined in <xref target="MODES" f
</t> ormat="default" sectionFormat="of" derivedContent="MODES"/> and
<t> the CTR-Encrypt(K, IV, S) function denotes the encryption of
where the OMAC function is defined in <xref target="MODES"/> message S on key K and nonce IV in the CTR mode with s = n (see <xref target="M
, ODES" format="default" sectionFormat="of" derivedContent="MODES"/>).
the CTR-Encrypt(K, IV, S) function denotes the encryption of </t>
message S on key K and nonce IV in the CTR mode with s = n (see <xref target="M <t indent="0" pn="section-8.2.1-5">
ODES"/>). The KImp15 key import algorithm is defined as follows:
</t> </t>
<t> <sourcecode type="pseudocode" markers="false" pn="section-8.2.1-6">
The KImp15 key import algorithm is defined as follows.
</t>
<t>
<figure>
<artwork>
<![CDATA[
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| KImp15(SExp, K_Exp_MAC, K_Exp_ENC, IV) | | KImp15(SExp, K_Exp_MAC, K_Exp_ENC, IV) |
|-------------------------------------------------------------------| |-------------------------------------------------------------------|
| Input: | | Input: |
| - export representation SExp in B* | | - export representation SExp in B* |
| - key K_Exp_MAC in B_k, | | - key K_Exp_MAC in B_k, |
| - key K_Exp_ENC in B_k, | | - key K_Exp_ENC in B_k, |
| - IV in B_{n/2} | | - IV in B_{n/2} |
| Output: | | Output: |
| - secret S in B_{L(SExp)-n} or FAIL | | - secret S in B_{L(SExp)-n} or FAIL |
|-------------------------------------------------------------------| |-------------------------------------------------------------------|
| 1. S | CEK_MAC = CTR-Decrypt(K_Exp_ENC, IV, SExp), CEK_MAC in B_n| | 1. S | CEK_MAC = CTR-Decrypt(K_Exp_ENC, IV, SExp), CEK_MAC in B_n|
| 2. If CEK_MAC = OMAC(K_Exp_MAC, IV | S) | | 2. If CEK_MAC = OMAC(K_Exp_MAC, IV | S) |
| then return S; else return FAIL | | then return S; else return FAIL |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
]]> </sourcecode>
</artwork> <t indent="0" pn="section-8.2.1-7">
</figure> where the OMAC function is defined in <xref target="MODES" f
</t> ormat="default" sectionFormat="of" derivedContent="MODES"/> and
<t> the CTR-Decrypt(K, IV, S) function denotes the decryption of
where the OMAC function is defined in <xref target="MODES"/> message S on key K and nonce IV in the CTR mode (see <xref target="MODES" forma
, t="default" sectionFormat="of" derivedContent="MODES"/>).
the CTR-Decrypt(K, IV, S) function denotes the decryption of </t>
message S on key K and nonce IV in the CTR mode (see <xref target="MODES"/>). <t indent="0" pn="section-8.2.1-8">
</t> The keys K_Exp_MAC and K_Exp_ENC <bcp14>MUST</bcp14> be inde
<t> pendent. For every pair of keys (K_Exp_ENC, K_Exp_MAC), the IV values <bcp14>MUS
The keys K_Exp_MAC and K_Exp_ENC MUST be independent. For ev T</bcp14> be unique.
ery pair of keys (K_Exp_ENC, K_Exp_MAC) the IV values MUST be unique. For the import of a key with the KImp15 algorithm, the IV va
For the import of key with the KImp15 algorithm, the IV valu lue may be sent with the export key representation.
e may be sent with the export key representation. </t>
</t> </section>
</section> <section anchor="KExpImp28147" numbered="true" toc="include" removeInRFC
="false" pn="section-8.2.2">
<section anchor ="KExpImp28147" title="KExp28147 and KImp28147 A <name slugifiedName="name-kexp28147-and-kimp28147-alg">KExp28147 and K
lgorithms"> Imp28147 Algorithms</name>
<t> <t indent="0" pn="section-8.2.2-1">
The KExp28147 key export algorithm is defined as follows The KExp28147 key export algorithm is defined as follows
. :
</t> </t>
<t> <sourcecode type="pseudocode" markers="false" pn="section-8.2.2-2">
<figure>
<artwork>
<![CDATA[
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| KExp28147(S, K, IV) | | KExp28147(S, K, IV) |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - secret S to be exported, S in B_32, | | - secret S to be exported, S in B_32, |
| - key K in B_32, | | - key K in B_32, |
| - IV in B_8. | | - IV in B_8. |
| Output: | | Output: |
| - export representation SExp in B_44 | | - export representation SExp in B_44 |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. CEK_MAC = gost28147IMIT(IV, K, S), CEK_MAC in B_4 | | 1. CEK_MAC = gost28147IMIT(IV, K, S), CEK_MAC in B_4 |
| 2. CEK_ENC = ECB-Encrypt(K, S), CEK_ENC in B_32 | | 2. CEK_ENC = ECB-Encrypt(K, S), CEK_ENC in B_32 |
| 3. return SExp = IV | CEK_ENC | CEK_MAC | | 3. return SExp = IV | CEK_ENC | CEK_MAC |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
]]></artwork> </sourcecode>
</figure> <t indent="0" pn="section-8.2.2-3">
</t> where the gost28147IMIT function is defined in <xref tar
<t> get="IMIT" format="default" sectionFormat="of" derivedContent="Section 8.4"/> an
where the gost28147IMIT function is defined in <xref tar d
get="IMIT"/>, the ECB-Encrypt(K, S) function denotes the encryption of
the ECB-Encrypt(K, S) function denotes the encryption of message S on key K with the block cipher GOST 28147-89 in the electronic codebo
message S on key K with the block cipher GOST 28147-89 in the ECB mode (see <xr ok (ECB) mode (see <xref target="RFC5830" format="default" sectionFormat="of" de
ef target ="RFC5830"/>). rivedContent="RFC5830"/>).
</t> </t>
<t> <t indent="0" pn="section-8.2.2-4">
The KImp28147 key import algorithm is defined as follows The KImp28147 key import algorithm is defined as follows
. :
</t> </t>
<t> <sourcecode type="pseudocode" markers="false" pn="section-8.2.2-5">
<figure>
<artwork>
<![CDATA[
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| KImp28147(SExp, K, IV) | | KImp28147(SExp, K, IV) |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - export representation SExp in B_44, | | - export representation SExp in B_44, |
| - key K in B_32, | | - key K in B_32, |
| - IV in B_8. | | - IV in B_8. |
| Output: | | Output: |
| - imported secret S in B_32 or FAIL | | - imported secret S in B_32 or FAIL |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. extract from SExp | | 1. extract from SExp |
| IV' = SExp[1..8], | | IV' = SExp[1..8], |
| CEK_ENC = SExp[9..40], | | CEK_ENC = SExp[9..40], |
| CEK_MAC = SExp[41..44] | | CEK_MAC = SExp[41..44] |
| 2. if IV' != IV then return FAIL; else | | 2. if IV' != IV then return FAIL; else |
| 3. S = ECB-Decrypt(K, CEK_ENC), S in B_32 | | 3. S = ECB-Decrypt(K, CEK_ENC), S in B_32 |
| 4. If CEK_MAC = gost28147IMIT(IV, K, S) | | 4. If CEK_MAC = gost28147IMIT(IV, K, S) |
| then return S; else return FAIL | | then return S; else return FAIL |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
]]></artwork> </sourcecode>
</figure> <t indent="0" pn="section-8.2.2-6">
</t> where the gost28147IMIT function is defined in <xref tar
<t> get="IMIT" format="default" sectionFormat="of" derivedContent="Section 8.4"/> an
where the gost28147IMIT function is defined in <xref tar d
get="IMIT"/>, the ECB-Decrypt(CEK_ENC, M) function denotes the decrypt
the ECB-Decrypt(CEK_ENC, M) function denotes the decrypt ion of ciphertext CEK_ENC on key K with a block cipher GOST 28147-89 in the ECB
ion of ciphertext CEK_ENC on key K with a block cipher GOST 28147-89 in the ECB mode (see <xref target="RFC5830" format="default" sectionFormat="of" derivedCont
mode (see <xref target ="RFC5830"/>). ent="RFC5830"/>).
</t> </t>
</section> </section>
</section> </section>
<section anchor="KEGAlgs" numbered="true" toc="include" removeInRFC="false
<section anchor ="KEGAlgs" title="Key Exchange Generation Algorithms " pn="section-8.3">
"> <name slugifiedName="name-key-exchange-generation-alg">Key Exchange Gene
<section anchor ="KEG" title="KEG Algorithm"> ration Algorithms</name>
<t> <section anchor="KEG" numbered="true" toc="include" removeInRFC="false"
pn="section-8.3.1">
<name slugifiedName="name-keg-algorithm">KEG Algorithm</name>
<t indent="0" pn="section-8.3.1-1">
The KEG algorithm is defined as follows: The KEG algorithm is defined as follows:
</t> </t>
<t> <sourcecode type="pseudocode" markers="false" pn="section-8.3.1-2">
<figure>
<artwork>
<![CDATA[
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| KEG(d, Q, H) | | KEG(d, Q, H) |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - private key d, | | - private key d, |
| - public key Q, | | - public key Q, |
| - H in B_32. | | - H in B_32. |
| Output: | | Output: |
| - key material K in B_64. | | - key material K in B_64. |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. If q * Q is not equal to zero point | | 1. If q * Q is not equal to zero point |
| return FAIL | | return FAIL |
| 2. If 2^{254} < q < 2^{256} | | 2. If 2^254 &lt; q &lt; 2^256 |
| return KEG_256(d, Q, H) | | return KEG_256(d, Q, H) |
| 3. If 2^{508} < q < 2^{512} | | 3. If 2^508 &lt; q &lt; 2^512 |
| return KEG_512(d, Q, H) | | return KEG_512(d, Q, H) |
| 4. return FAIL | | 4. return FAIL |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
]]></artwork> </sourcecode>
</figure> <t indent="0" pn="section-8.3.1-3">
</t>
<t>
where q is an order of a cyclic subgroup of elliptic cur ve points group containing point Q, d in {1, ... , q - 1}. where q is an order of a cyclic subgroup of elliptic cur ve points group containing point Q, d in {1, ... , q - 1}.
</t> </t>
<t> <t indent="0" pn="section-8.3.1-4">
The KEG_256 algorithm is defined as follows: The KEG_256 algorithm is defined as follows:
</t> </t>
<t> <sourcecode type="pseudocode" markers="false" pn="section-8.3.1-5">
<figure>
<artwork>
<![CDATA[
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| KEG_256(d, Q, H) | | KEG_256(d, Q, H) |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - private key d, | | - private key d, |
| - public key Q, | | - public key Q, |
| - H in B_32. | | - H in B_32. |
| Output: | | Output: |
| - key material K in B_64. | | - key material K in B_64. |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. r = INT(H[1..16]) | | 1. r = INT(H[1..16]) |
| 2. If r = 0 | | 2. If r = 0 |
| UKM = 1; else UKM = r | | UKM = 1; else UKM = r |
| 3. K_EXP = VKO_256(d, Q, UKM) | | 3. K_EXP = VKO_256(d, Q, UKM) |
| 4. seed = H[17..24] | | 4. seed = H[17..24] |
| 5. return KDFTREE_256(K_EXP, "kdf tree", seed, 1) | | 5. return KDFTREE_256(K_EXP, "kdf tree", seed, 1) |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
]]></artwork> </sourcecode>
</figure> <t indent="0" pn="section-8.3.1-6">
</t> where VKO_256 is the function VKO_GOSTR3410_2012_256 def
<t> ined in <xref target="RFC7836" format="default" sectionFormat="of" derivedConten
where VKO_256 is the function VKO_GOSTR3410_2012_256 def t="RFC7836"/> and
ined in <xref target="RFC7836"/> and KDFTREE_256 is the KDF_TREE_GOSTR3411_2012_256 function
KDFTREE_256 is the KDF_TREE_GOSTR3411_2012_256 function defined in <xref target="RFC7836" format="default" sectionFormat="of" derivedCon
defined in <xref target="RFC7836"/> with the parameter L equal to 512. tent="RFC7836"/> with the parameter L equal to 512.
</t> </t>
<t> <t indent="0" pn="section-8.3.1-7">
The KEG_512 algorithm is defined as follows: The KEG_512 algorithm is defined as follows:
</t> </t>
<t> <sourcecode type="pseudocode" markers="false" pn="section-8.3.1-8">
<figure>
<artwork>
<![CDATA[
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| KEG_512(d, Q, H) | | KEG_512(d, Q, H) |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - private key d, | | - private key d, |
| - public key Q, | | - public key Q, |
| - H in B_32. | | - H in B_32. |
| Output: | | Output: |
| - key material K in B_64. | | - key material K in B_64. |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. r = INT(H[1..16]) | | 1. r = INT(H[1..16]) |
| 2. If r = 0 | | 2. If r = 0 |
| UKM = 1; else UKM = r | | UKM = 1; else UKM = r |
| 3. return VKO_512(d, Q, UKM) | | 3. return VKO_512(d, Q, UKM) |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
]]></artwork> </sourcecode>
</figure> <t indent="0" pn="section-8.3.1-9">
</t> where VKO_512 is the VKO_GOSTR3410_2012_512 function def
<t> ined in <xref target="RFC7836" format="default" sectionFormat="of" derivedConten
where VKO_512 is the VKO_GOSTR3410_2012_512 function def t="RFC7836"/>.
ined in <xref target="RFC7836"/>. </t>
</t> </section>
</section> <section anchor="KEG_28147" numbered="true" toc="include" removeInRFC="f
<section anchor ="KEG_28147" title="KEG_28147 Algorithm"> alse" pn="section-8.3.2">
<t> <name slugifiedName="name-keg_28147-algorithm">KEG_28147 Algorithm</na
me>
<t indent="0" pn="section-8.3.2-1">
The KEG_28147 algorithm is defined as follows: The KEG_28147 algorithm is defined as follows:
</t> </t>
<t> <sourcecode type="pseudocode" markers="false" pn="section-8.3.2-2">
<figure>
<artwork>
<![CDATA[
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| KEG_28147(d, Q, H) | | KEG_28147(d, Q, H) |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - private key d, | | - private key d, |
| - public key Q, | | - public key Q, |
| - H in B_32. | | - H in B_32. |
| Output: | | Output: |
| - key material K in B_32. | | - key material K in B_32. |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. If q * Q is not equal to zero point | | 1. If q * Q is not equal to zero point |
| return FAIL | | return FAIL |
| 2. UKM = H[1..8] | | 2. UKM = H[1..8] |
| 3. R = VKO_256(d, Q, int(UKM)) | | 3. R = VKO_256(d, Q, int(UKM)) |
| 4. return K = CPDivers(UKM, R) | | 4. return K = CPDivers(UKM, R) |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
]]></artwork> </sourcecode>
</figure> <t indent="0" pn="section-8.3.2-3">
</t> where the VKO_256 function is equal to the VKO_GOSTR3410
<t> _2012_256 function defined in <xref target="RFC7836" format="default" sectionFor
where the VKO_256 function is equal to the VKO_GOSTR3410 mat="of" derivedContent="RFC7836"/> and
_2012_256 function defined in <xref target="RFC7836"/>, the CPDivers function corresponds to the CryptoPro KEK D
the CPDivers function corresponds to the CryptoPro KEK D iversification Algorithm defined in <xref target="RFC4357" format="default" sect
iversification Algorithm defined in <xref target="RFC4357"/>, which takes as inp ionFormat="of" derivedContent="RFC4357"/>, which takes as input the User Keying
ut the UKM value and the key value. Material (UKM) value and the key value.
</t> </t>
</section> </section>
</section> </section>
<section anchor="IMIT" numbered="true" toc="include" removeInRFC="false" p
<section anchor ="IMIT" title="gostIMIT28147"> n="section-8.4">
<t> <name slugifiedName="name-gostimit28147">gostIMIT28147</name>
gost28147IMIT(IV, K, M) is a MAC algorithm with 4 bytes outpu <t indent="0" pn="section-8.4-1">
t and is defined as follows: gost28147IMIT(IV, K, M) is a MAC algorithm with a 4-byte outp
</t> ut and is defined as follows:
<t> </t>
<figure> <sourcecode type="pseudocode" markers="false" pn="section-8.4-2">
<artwork>
<![CDATA[
+----------------------------------------------------------------+ +----------------------------------------------------------------+
| gost28147IMIT(IV, K, M) | | gost28147IMIT(IV, K, M) |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Input: | | Input: |
| - initial value IV in B_8, | | - initial value IV in B_8, |
| - key K in B_32, | | - key K in B_32, |
| - message M in B*. | | - message M in B*. |
| Output: | | Output: |
| - MAC value T in B_4. | | - MAC value T in B_4. |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| 1. M' = PAD(M) | | 1. M' = PAD(M) |
| 2. M' = M'_0 | ... | M'_r, L(M'_i) = 8, i in {0, ... , r} | | 2. M' = M'_0 | ... | M'_r, L(M'_i) = 8, i in {0, ... , r} |
| 3. M'' = (M'_0 XOR IV) | M'_1 | ... | M'_r | | 3. M'' = (M'_0 XOR IV) | M'_1 | ... | M'_r |
| 4. return T = MAC28147(K, M'') | | 4. return T = MAC28147(K, M'') |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
]]></artwork> </sourcecode>
</figure> <t indent="0" pn="section-8.4-3">
</t>
<t>
where the PAD function is the padding function that adds m z ero bytes to the end of the message, where the PAD function is the padding function that adds m z ero bytes to the end of the message,
where m is the smallest, non-negative solution to the equati m is the smallest, non-negative solution to the equation (L(
on (L(M) + m) mod 8 = 0, M) + m) mod 8 = 0, and
the MAC28147 function corresponds to Message Authentication the MAC28147 function corresponds to the MAC generation mode
Code Generation Mode defined in <xref target="RFC5830" format="default" sectionFo
defined in <xref target ="RFC5830"/> with 4 byte length outp rmat="of" derivedContent="RFC5830"/> with a 4-byte length output.
ut. </t>
</t> </section>
</section> </section>
</section> <section anchor="IANACON" numbered="true" toc="include" removeInRFC="false"
pn="section-9">
<section anchor="IANACON" title="IANA Considerations"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t> <t indent="0" pn="section-9-1">
IANA is asked to update the registry entries to reference this d IANA has added the following values to the "TLS Cipher Suites" registry:
ocument when it is published as an RFC. </t>
</t> <table align="center" pn="table-4">
<t> <thead>
IANA has added numbers {0xC1, 0x00}, {0xC1, 0x01} and {0xC1, 0x0 <tr>
2} with the names <th align="left" colspan="1" rowspan="1">Value</th>
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC, <th align="left" colspan="1" rowspan="1">Description</th>
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC, <th align="left" colspan="1" rowspan="1">DTLS-OK</th>
TLS_GOSTR341112_256_WITH_28147_CNT_IMIT to <th align="left" colspan="1" rowspan="1">Recommended</th>
the "TLS Cipher Suite" registry with this document as reference, <th align="left" colspan="1" rowspan="1">Reference</th>
as shown below. </tr>
</t> </thead>
<t> <tbody>
<figure> <tr>
<artwork> <td align="left" colspan="1" rowspan="1">0xC1,0x00</td>
<![CDATA[ <td align="left" colspan="1" rowspan="1">TLS_GOSTR341112_256_​WITH_K
+-------------+-----------------------------+---------+----------+ UZNYECHIK_CTR_OMAC</td>
| Value | Description | DTLS-OK | Reference| <td align="left" colspan="1" rowspan="1">N</td>
+-------------+-----------------------------+---------+----------+ <td align="left" colspan="1" rowspan="1">N</td>
| 0xC1, 0x00 | TLS_GOSTR341112_256_ | N | this RFC | <td align="left" colspan="1" rowspan="1">RFC 9189</td>
| | _WITH_KUZNYECHIK_CTR_OMAC | | | </tr>
+-------------+-----------------------------+---------+----------+ <tr>
| 0xC1, 0x01 | TLS_GOSTR341112_256_ | N | this RFC | <td align="left" colspan="1" rowspan="1">0xC1,0x01</td>
| | _WITH_MAGMA_CTR_OMAC | | | <td align="left" colspan="1" rowspan="1">TLS_GOSTR341112_256_​WITH_M
+-------------+-----------------------------+---------+----------+ AGMA_CTR_OMAC</td>
| 0xC1, 0x02 | TLS_GOSTR341112_256_ | N | this RFC | <td align="left" colspan="1" rowspan="1">N</td>
| | _WITH_28147_CNT_IMIT | | | <td align="left" colspan="1" rowspan="1">N</td>
+-------------+-----------------------------+---------+----------+ <td align="left" colspan="1" rowspan="1">RFC 9189</td>
Table 4 </tr>
]]></artwork> <tr>
</figure> <td align="left" colspan="1" rowspan="1"> 0xC1,0x02</td>
</t> <td align="left" colspan="1" rowspan="1">TLS_GOSTR341112_256_​WITH_2
<t> 8147_CNT_IMIT</td>
IANA has added numbers 64, 65 with the names <td align="left" colspan="1" rowspan="1">N</td>
gostr34102012_256, <td align="left" colspan="1" rowspan="1">N</td>
gostr34102012_512, <td align="left" colspan="1" rowspan="1">RFC 9189</td>
to the "TLS SignatureAlgorithm" registry, as shown below. </tr>
</t> </tbody>
<t> </table>
<figure> <t indent="0" pn="section-9-3">
<artwork> IANA has added the following values to the "TLS SignatureAlgorithm" regi
<![CDATA[ stry:
+-----------+---------------------+---------+----------+ </t>
| Value | Description | DTLS-OK | Reference| <table align="center" pn="table-5">
+-----------+---------------------+---------+----------+ <thead>
| 64 | gostr34102012_256 | Y | this RFC | <tr>
+-----------+---------------------+---------+----------+ <th align="left" colspan="1" rowspan="1">Value</th>
| 65 | gostr34102012_512 | Y | this RFC | <th align="left" colspan="1" rowspan="1">Description</th>
+-----------+---------------------+---------+----------+ <th align="left" colspan="1" rowspan="1">DTLS-OK</th>
Table 5 <th align="left" colspan="1" rowspan="1">Reference</th>
]]></artwork> </tr>
</figure> </thead>
</t> <tbody>
<t> <tr>
IANA is asked to reserve the numbers 0x0840, 0x0841 for backward <td align="left" colspan="1" rowspan="1">64</td>
compatibility <td align="left" colspan="1" rowspan="1">gostr34102012_256</td>
to the "TLS SignatureScheme" registry with this document as refe <td align="left" colspan="1" rowspan="1">Y</td>
rence, as shown below. <td align="left" colspan="1" rowspan="1">RFC 9189</td>
</t> </tr>
<t> <tr>
<figure> <td align="left" colspan="1" rowspan="1">65</td>
<artwork> <td align="left" colspan="1" rowspan="1">gostr34102012_512</td>
<![CDATA[ <td align="left" colspan="1" rowspan="1">Y</td>
+--------+-------------------------------------+----------+---------+ <td align="left" colspan="1" rowspan="1">RFC 9189</td>
| Value | Description |Recomended|Reference| </tr>
+--------+-------------------------------------+----------+---------+ </tbody>
| 0x0840 | Reserved for backward compatibility | N |this RFC | </table>
+--------+-------------------------------------+----------+---------+ <t indent="0" pn="section-9-5">
| 0x0841 | Reserved for backward compatibility | N |this RFC | IANA has added the following values to the "TLS SignatureScheme" registr
+--------+-------------------------------------+----------+---------+ y:
Table 6 </t>
]]></artwork> <table align="center" pn="table-6">
</figure> <thead>
</t> <tr>
<t> <th align="left" colspan="1" rowspan="1">Value</th>
IANA is requested to add a note to the allocated TLS SignatureAl <th align="left" colspan="1" rowspan="1">Description</th>
gorithm values 64 and 65, reading "These values were allocated from the Reserved <th align="left" colspan="1" rowspan="1">Recommended</th>
state due to a misunderstanding of the difference between Reserved and Unalloca <th align="left" colspan="1" rowspan="1">Reference</th>
ted that went undetected for a long time. </tr>
Additional allocations from the Reserved state are not expected, </thead>
and the TLS SignatureScheme registry is suitable for use for new allocations in <tbody>
stead of this registry". <tr>
</t> <td align="left" colspan="1" rowspan="1">0x0840</td>
<t> <td align="left" colspan="1" rowspan="1">Reserved for backward compa
IANA has added numbers 34, 35, 36, 37, 38, 39, 40 with the names tibility</td>
GC256A, <td align="left" colspan="1" rowspan="1">N</td>
GC256B, <td align="left" colspan="1" rowspan="1">RFC 9189</td>
GC256C, </tr>
GC256D, <tr>
GC512A, <td align="left" colspan="1" rowspan="1">0x0841</td>
GC512B, <td align="left" colspan="1" rowspan="1">Reserved for backward compa
GC512C tibility</td>
to the "TLS Supported Groups" registry, as shown below. <td align="left" colspan="1" rowspan="1">N</td>
</t> <td align="left" colspan="1" rowspan="1">RFC 9189</td>
<t> </tr>
<figure> </tbody>
<artwork> </table>
<![CDATA[ <t indent="0" pn="section-9-7">
+-----------+----------------+---------+------------+-----------+ IANA has also added the following footnote to values 64 and 65 in the "T
| Value | Description | DTLS-OK | Recomended | Reference | LS SignatureAlgorithm" registry:
+-----------+----------------+---------+------------+-----------+ </t>
| 34 | GC256A | Y | N | this RFC | <blockquote pn="section-9-8">These values were allocated from the Reserved
+-----------+----------------+---------+------------+-----------+ state due to a misunderstanding of the difference between Reserved and Unalloca
| 35 | GC256B | Y | N | this RFC | ted that went undetected for a long time.
+-----------+----------------+---------+------------+-----------+ Additional allocations from the Reserved state are not expected,
| 36 | GC256C | Y | N | this RFC | and the TLS SignatureScheme registry is suitable for use for new allocations in
+-----------+----------------+---------+------------+-----------+ stead of this registry.
| 37 | GC256D | Y | N | this RFC | </blockquote>
+-----------+----------------+---------+------------+-----------+ <t indent="0" pn="section-9-9">
| 38 | GC512A | Y | N | this RFC | IANA has added the following values to the "TLS Supported Groups" registr
+-----------+----------------+---------+------------+-----------+ y:
| 39 | GC512B | Y | N | this RFC | </t>
+-----------+----------------+---------+------------+-----------+ <table align="center" pn="table-7">
| 40 | GC512C | Y | N | this RFC | <thead>
+-----------+----------------+---------+------------+-----------+ <tr>
Table 7 <th align="left" colspan="1" rowspan="1">Value</th>
]]></artwork> <th align="left" colspan="1" rowspan="1">Description</th>
</figure> <th align="left" colspan="1" rowspan="1">DTLS-OK</th>
</t> <th align="left" colspan="1" rowspan="1">Recommended</th>
<t> <th align="left" colspan="1" rowspan="1">Reference</th>
IANA has added numbers 67, 68 with the names gost_sign256, gost_ </tr>
sign512 </thead>
to the "ClientCertificateType Identifiers" registry, as shown be <tbody>
low. <tr>
</t> <td align="left" colspan="1" rowspan="1">34</td>
<t> <td align="left" colspan="1" rowspan="1">GC256A</td>
<figure> <td align="left" colspan="1" rowspan="1">Y</td>
<artwork> <td align="left" colspan="1" rowspan="1">N</td>
<![CDATA[ <td align="left" colspan="1" rowspan="1">RFC 9189</td>
+-----------+---------------------+---------+----------+ </tr>
| Value | Description | DTLS-OK | Reference| <tr>
+-----------+---------------------+---------+----------+ <td align="left" colspan="1" rowspan="1">35</td>
| 67 | gost_sign256 | Y | this RFC | <td align="left" colspan="1" rowspan="1">GC256B</td>
+-----------+---------------------+---------+----------+ <td align="left" colspan="1" rowspan="1">Y</td>
| 68 | gost_sign512 | Y | this RFC | <td align="left" colspan="1" rowspan="1">N</td>
+-----------+---------------------+---------+----------+ <td align="left" colspan="1" rowspan="1">RFC 9189</td>
Table 8 </tr>
]]> <tr>
</artwork> <td align="left" colspan="1" rowspan="1">36</td>
</figure> <td align="left" colspan="1" rowspan="1">GC256C</td>
</t> <td align="left" colspan="1" rowspan="1">Y</td>
</section> <td align="left" colspan="1" rowspan="1">N</td>
<section anchor="Historical" title="Historical Considerations"> <td align="left" colspan="1" rowspan="1">RFC 9189</td>
<t> </tr>
Note that prior to the existence of this document implementation <tr>
s could use only the values from the Private Use space in order to use the GOST- <td align="left" colspan="1" rowspan="1">37</td>
based algorithms. <td align="left" colspan="1" rowspan="1">GC256D</td>
So some old implementations <td align="left" colspan="1" rowspan="1">Y</td>
can still use the old value {0xFF, 0x85} instead of the {0xC1, 0 <td align="left" colspan="1" rowspan="1">N</td>
x02} value to indicate the TLS_GOSTR341112_256_WITH_28147_CNT_IMIT cipher suite; <td align="left" colspan="1" rowspan="1">RFC 9189</td>
one old value 0xEE instead of the values 64, 8 and 67 (to indica </tr>
te the gostr34102012_256 signature algorithm, the Intrinsic hash algorithm and t <tr>
he gost_sign256 certificate type respectively); <td align="left" colspan="1" rowspan="1">38</td>
one old value 0xEF instead of the values 65, 8 and 68 (to indica <td align="left" colspan="1" rowspan="1">GC512A</td>
te the gostr34102012_512 signature algorithm, the Intrinsic hash algorithm and t <td align="left" colspan="1" rowspan="1">Y</td>
he gost_sign512 certificate type respectively). <td align="left" colspan="1" rowspan="1">N</td>
</t> <td align="left" colspan="1" rowspan="1">RFC 9189</td>
<t> </tr>
Due to historical reasons in addition to the curve identifier va <tr>
lues listed in Table 2 <td align="left" colspan="1" rowspan="1">39</td>
<td align="left" colspan="1" rowspan="1">GC512B</td>
<td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">N</td>
<td align="left" colspan="1" rowspan="1">RFC 9189</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">40</td>
<td align="left" colspan="1" rowspan="1">GC512C</td>
<td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">N</td>
<td align="left" colspan="1" rowspan="1">RFC 9189</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-9-11">
IANA has added the following values to the "TLS ClientCertificateType Ide
ntifiers" registry:
</t>
<table align="center" pn="table-8">
<thead>
<tr>
<td align="left" colspan="1" rowspan="1">Value</td>
<td align="left" colspan="1" rowspan="1">Description</td>
<td align="left" colspan="1" rowspan="1">DTLS-OK</td>
<td align="left" colspan="1" rowspan="1">Reference</td>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">67</td>
<td align="left" colspan="1" rowspan="1">gost_sign256</td>
<td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">RFC 9189</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">68</td>
<td align="left" colspan="1" rowspan="1">gost_sign512</td>
<td align="left" colspan="1" rowspan="1">Y</td>
<td align="left" colspan="1" rowspan="1">RFC 9189</td>
</tr>
</tbody>
</table>
</section>
<section anchor="Historical" numbered="true" toc="include" removeInRFC="fals
e" pn="section-10">
<name slugifiedName="name-historical-considerations">Historical Considerat
ions</name>
<t indent="0" pn="section-10-1">
Note that prior to the existence of this document, implementations co
uld use only the values from the "Private Use" space in order to use the GOST-ba
sed algorithms.
So some old implementations can still use the old value {0xFF, 0x85}
instead of the {0xC1, 0x02} value to indicate the TLS_GOSTR341112_256_WITH_28147
_CNT_IMIT cipher suite;
the old value 0xEE instead of the values 64, 8, and 67 (to indicate t
he gostr34102012_256 signature algorithm, the Intrinsic hash algorithm, and the
gost_sign256 certificate type, respectively);
the old value 0xEF instead of the values 65, 8, and 68 (to indicate t
he gostr34102012_512 signature algorithm, the Intrinsic hash algorithm, and the
gost_sign512 certificate type, respectively).
</t>
<t indent="0" pn="section-10-2">
Due to historical reasons, in addition to the curve identifier v
alues listed in <xref target="tab-2" format="default" sectionFormat="of" derived
Content="Table 2"/>,
there exist some extra identifier values that correspond to there exist some extra identifier values that correspond to
the curves GC256B, GC256C and GC256D as follows (see <xref targe the curves GC256B, GC256C, and GC256D as follows (see <xref targ
t =" RFC4357"/>, <xref target="R-1323565.1.024-2019"/>). et="RFC4357" format="default" sectionFormat="of" derivedContent="RFC4357"/> and
</t> <xref target="R-1323565.1.024-2019" format="default" sectionFormat="of" derivedC
<t> ontent="R-1323565.1.024-2019"/>).
<figure> </t>
<artwork> <table align="center" pn="table-9">
<![CDATA[ <thead>
+-------------+-----------------------------------------+ <tr>
| Description | Curve Identifier Values | <th align="left" colspan="1" rowspan="1">Description</th>
+-------------+-----------------------------------------+ <th align="left" colspan="1" rowspan="1">Curve Identifier Values</th
| GC256B |id-GostR3410_2001-CryptoPro-XchA-ParamSet| >
| |id-tc26-gost-3410-2012-256-paramSetB | </tr>
+-------------+-----------------------------------------+ </thead>
| GC256C |id-tc26-gost-3410-2012-256-paramSetC | <tbody>
+-------------+-----------------------------------------+ <tr>
| GC256D |id-GostR3410-2001-CryptoPro-XchB-ParamSet| <td align="left" colspan="1" rowspan="1">GC256B</td>
| |id-tc26-gost-3410-2012-256-paramSetD | <td align="left" colspan="1" rowspan="1">
+-------------+-----------------------------------------+ <ul empty="true" bare="true" spacing="compact" indent="3" pn="sect
Table 9 ion-10-3.2.1.2.1">
]]> <li pn="section-10-3.2.1.2.1.1">id-GostR3410_2001-CryptoPro-XchA
</artwork> -ParamSet</li>
</figure> <li pn="section-10-3.2.1.2.1.2">id-tc26-gost-3410-2012-256-param
</t> SetB</li>
<t> </ul>
Client should be prepared to handle any of them correctly if cor </td>
responding group is included in the supported_groups extension (see <xref target </tr>
="RFC8422"/> and <xref target="RFC7919"/>). <tr>
</t> <td align="left" colspan="1" rowspan="1">GC256C</td>
</section> <td align="left" colspan="1" rowspan="1">id-tc26-gost-3410-2012-256-
paramSetC</td>
<section anchor="Security" title="Security Considerations"> </tr>
<t> <tr>
<td align="left" colspan="1" rowspan="1">GC256D</td>
<td align="left" colspan="1" rowspan="1">
<ul empty="true" bare="true" spacing="compact" indent="3" pn="sect
ion-10-3.2.3.2.1">
<li pn="section-10-3.2.3.2.1.1">id-GostR3410-2001-CryptoPro-XchB
-ParamSet</li>
<li pn="section-10-3.2.3.2.1.2">id-tc26-gost-3410-2012-256-param
SetD</li>
</ul>
</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-10-4">
The client should be prepared to handle any of these correctly i
f the corresponding group is included in the supported_groups extension (see <xr
ef target="RFC8422" format="default" sectionFormat="of" derivedContent="RFC8422"
/> and <xref target="RFC7919" format="default" sectionFormat="of" derivedContent
="RFC7919"/>).
</t>
</section>
<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
pn="section-11">
<name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-11-1">
The cipher suites defined in this document do not provide Perfec t Forward Secrecy. The cipher suites defined in this document do not provide Perfec t Forward Secrecy.
</t> </t>
<t> <t indent="0" pn="section-11-2">
The authenticate-then-encrypt method is crucial for the CNT_IMIT
cipher suite. Encryption of the MAC value is conducted to reduce the possibilit
y of forgery to guessing.
Here the probability of guess is approximately equal to 2^{-32},
which is acceptable in some practical cases.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5830.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5246.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7801.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6986.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7091.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7627.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5746.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7836.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4357.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4490.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8422.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7919.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7366.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8645.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8446.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8891.xml' ?>
</references>
<references title="Informative References">
<reference anchor="IK2003">
<front>
<title>
OMAC: One-Key CBC MAC.
</title>
<author>
<organization>
Iwata T., Kurosawa K. (2003)
</organization>
</author>
<date year="2003"/>
</front>
<seriesInfo name="FSE 2003. Lecture Notes in Computer Science,
" value="vol 2887. Springer, Berlin, Heidelberg"/>
</reference>
<reference anchor="CMAC"> The authenticate-then-encrypt method is crucial for the CNT_IMIT
<front> cipher suite. Encryption of the MAC value is conducted to reduce the possibilit
<title> y of forgery to guessing.
Recommendation for Block Cipher Modes of Operation: the Here, the probability of a guess is approximately equal to 2<sup
CMAC Mode for Authentication >-32</sup>, which is acceptable in some practical cases.
</title> </t>
<author> </section>
<organization> </middle>
Dworkin, M. <back>
</organization> <displayreference target="I-D.smyshlyaev-tls13-gost-suites" to="DraftGostTLS
</author> 13"/>
<date year="2005"/> <displayreference target="I-D.ietf-tls-rfc8446bis" to="RFC8446bis"/>
</front> <references pn="section-12">
<seriesInfo name="NIST Special Publication" value="800-38B"/> <name slugifiedName="name-references">References</name>
</reference> <references pn="section-12.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="March"/>
<abstract>
<t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often ca
pitalized. This document defines these words as they should be interpreted in IE
TF documents. This document specifies an Internet Best Current Practices for th
e Internet Community, and requests discussion and suggestions for improvements.<
/t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC4357" target="https://www.rfc-editor.org/info/rfc4
357" quoteTitle="true" derivedAnchor="RFC4357">
<front>
<title>Additional Cryptographic Algorithms for Use with GOST 28147-8
9, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms</title>
<author initials="V." surname="Popov" fullname="V. Popov">
<organization showOnFrontPage="true"/>
</author>
<author initials="I." surname="Kurepkin" fullname="I. Kurepkin">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Leontiev" fullname="S. Leontiev">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="January"/>
<abstract>
<t indent="0">This document describes the cryptographic algorithms
and parameters supplementary to the original GOST specifications, GOST 28147-89
, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use in Internet a
pplications. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4357"/>
<seriesInfo name="DOI" value="10.17487/RFC4357"/>
</reference>
<reference anchor="RFC4490" target="https://www.rfc-editor.org/info/rfc4
490" quoteTitle="true" derivedAnchor="RFC4490">
<front>
<title>Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, an
d GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)</title>
<author initials="S." surname="Leontiev" fullname="S. Leontiev" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Chudov" fullname="G. Chudov" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="May"/>
<abstract>
<t indent="0">This document describes the conventions for using th
e cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, an
d GOST R 34.11-94 with the Cryptographic Message Syntax (CMS). The CMS is used
for digital signature, digest, authentication, and encryption of arbitrary messa
ge contents. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4490"/>
<seriesInfo name="DOI" value="10.17487/RFC4490"/>
</reference>
<reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5
246" quoteTitle="true" derivedAnchor="RFC5246">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
e>
<author initials="T." surname="Dierks" fullname="T. Dierks">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="August"/>
<abstract>
<t indent="0">This document specifies Version 1.2 of the Transport
Layer Security (TLS) protocol. The TLS protocol provides communications securi
ty over the Internet. The protocol allows client/server applications to communi
cate in a way that is designed to prevent eavesdropping, tampering, or message f
orgery. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5246"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
</reference>
<reference anchor="RFC5746" target="https://www.rfc-editor.org/info/rfc5
746" quoteTitle="true" derivedAnchor="RFC5746">
<front>
<title>Transport Layer Security (TLS) Renegotiation Indication Exten
sion</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Ray" fullname="M. Ray">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Dispensa" fullname="S. Dispensa">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Oskov" fullname="N. Oskov">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="February"/>
<abstract>
<t indent="0">Secure Socket Layer (SSL) and Transport Layer Securi
ty (TLS) renegotiation are vulnerable to an attack in which the attacker forms a
TLS connection with the target server, injects content of his choice, and then
splices in a new TLS connection from a client. The server treats the client's i
nitial TLS handshake as a renegotiation and thus believes that the initial data
transmitted by the attacker is from the same entity as the subsequent client dat
a. This specification defines a TLS extension to cryptographically tie renegoti
ations to the TLS connections they are being performed over, thus preventing thi
s attack. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5746"/>
<seriesInfo name="DOI" value="10.17487/RFC5746"/>
</reference>
<reference anchor="RFC5830" target="https://www.rfc-editor.org/info/rfc5
830" quoteTitle="true" derivedAnchor="RFC5830">
<front>
<title>GOST 28147-89: Encryption, Decryption, and Message Authentica
tion Code (MAC) Algorithms</title>
<author initials="V." surname="Dolmatov" fullname="V. Dolmatov" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="March"/>
<abstract>
<t indent="0">This document is intended to be a source of informat
ion about the Russian Federal standard for electronic encryption, decryption, an
d message authentication algorithms (GOST 28147-89), which is one of the Russian
cryptographic standard algorithms called GOST algorithms). Recently, Russian c
ryptography is being used in Internet applications, and this document has been c
reated as information for developers and users of GOST 28147-89 for encryption,
decryption, and message authentication. This document is not an Internet Stand
ards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5830"/>
<seriesInfo name="DOI" value="10.17487/RFC5830"/>
</reference>
<reference anchor="RFC6986" target="https://www.rfc-editor.org/info/rfc6
986" quoteTitle="true" derivedAnchor="RFC6986">
<front>
<title>GOST R 34.11-2012: Hash Function</title>
<author initials="V." surname="Dolmatov" fullname="V. Dolmatov" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Degtyarev" fullname="A. Degtyarev">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="August"/>
<abstract>
<t indent="0">This document is intended to be a source of informat
ion about the Russian Federal standard hash function (GOST R 34.11-2012), which
is one of the Russian cryptographic standard algorithms (called GOST algorithms)
. This document updates RFC 5831.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6986"/>
<seriesInfo name="DOI" value="10.17487/RFC6986"/>
</reference>
<reference anchor="RFC7091" target="https://www.rfc-editor.org/info/rfc7
091" quoteTitle="true" derivedAnchor="RFC7091">
<front>
<title>GOST R 34.10-2012: Digital Signature Algorithm</title>
<author initials="V." surname="Dolmatov" fullname="V. Dolmatov" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Degtyarev" fullname="A. Degtyarev">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="December"/>
<abstract>
<t indent="0">This document provides information about the Russian
Federal standard for digital signatures (GOST R 34.10-2012), which is one of th
e Russian cryptographic standard algorithms (called GOST algorithms). Recently,
Russian cryptography is being used in Internet applications, and this document p
rovides information for developers and users of GOST R 34.10-2012 regarding digi
tal signature generation and verification. This document updates RFC 5832.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7091"/>
<seriesInfo name="DOI" value="10.17487/RFC7091"/>
</reference>
<reference anchor="RFC7366" target="https://www.rfc-editor.org/info/rfc7
366" quoteTitle="true" derivedAnchor="RFC7366">
<front>
<title>Encrypt-then-MAC for Transport Layer Security (TLS) and Datag
ram Transport Layer Security (DTLS)</title>
<author initials="P." surname="Gutmann" fullname="P. Gutmann">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="September"/>
<abstract>
<t indent="0">This document describes a means of negotiating the u
se of the encrypt-then-MAC security mechanism in place of the existing MAC-then-
encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer
Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a numb
er of security vulnerabilities over a period of many years.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7366"/>
<seriesInfo name="DOI" value="10.17487/RFC7366"/>
</reference>
<reference anchor="RFC7627" target="https://www.rfc-editor.org/info/rfc7
627" quoteTitle="true" derivedAnchor="RFC7627">
<front>
<title>Transport Layer Security (TLS) Session Hash and Extended Mast
er Secret Extension</title>
<author initials="K." surname="Bhargavan" fullname="K. Bhargavan" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Delignat-Lavaud" fullname="A. Deligna
t-Lavaud">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Pironti" fullname="A. Pironti">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Langley" fullname="A. Langley">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Ray" fullname="M. Ray">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="September"/>
<abstract>
<t indent="0">The Transport Layer Security (TLS) master secret is
not cryptographically bound to important session parameters such as the server c
ertificate. Consequently, it is possible for an active attacker to set up two s
essions, one with a client and another with a server, such that the master secre
ts on the two sessions are the same. Thereafter, any mechanism that relies on t
he master secret for authentication, including session resumption, becomes vulne
rable to a man-in-the-middle attack, where the attacker can simply forward messa
ges back and forth between the client and server. This specification defines a
TLS extension that contextually binds the master secret to a log of the full han
dshake that computes it, thus preventing such attacks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7627"/>
<seriesInfo name="DOI" value="10.17487/RFC7627"/>
</reference>
<reference anchor="RFC7801" target="https://www.rfc-editor.org/info/rfc7
801" quoteTitle="true" derivedAnchor="RFC7801">
<front>
<title>GOST R 34.12-2015: Block Cipher "Kuznyechik"</title>
<author initials="V." surname="Dolmatov" fullname="V. Dolmatov" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="March"/>
<abstract>
<t indent="0">This document is intended to be a source of informat
ion about the Russian Federal standard GOST R 34.12-2015 describing the block ci
pher with a block length of n=128 bits and a key length of k=256 bits, which is
also referred to as "Kuznyechik". This algorithm is one of the set of Russian c
ryptographic standard algorithms (called GOST algorithms).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7801"/>
<seriesInfo name="DOI" value="10.17487/RFC7801"/>
</reference>
<reference anchor="RFC7836" target="https://www.rfc-editor.org/info/rfc7
836" quoteTitle="true" derivedAnchor="RFC7836">
<front>
<title>Guidelines on the Cryptographic Algorithms to Accompany the U
sage of Standards GOST R 34.10-2012 and GOST R 34.11-2012</title>
<author initials="S." surname="Smyshlyaev" fullname="S. Smyshlyaev"
role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Alekseev" fullname="E. Alekseev">
<organization showOnFrontPage="true"/>
</author>
<author initials="I." surname="Oshkin" fullname="I. Oshkin">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Popov" fullname="V. Popov">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Leontiev" fullname="S. Leontiev">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Podobaev" fullname="V. Podobaev">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Belyavsky" fullname="D. Belyavsky">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="March"/>
<abstract>
<t indent="0">The purpose of this document is to make the specific
ations of the cryptographic algorithms defined by the Russian national standards
GOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for
their implementation in the cryptographic protocols based on the accompanying a
lgorithms.</t>
<t indent="0">These specifications define the pseudorandom functio
ns, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash
function, the parameters of elliptic curves, the key derivation functions, and
the key export functions.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7836"/>
<seriesInfo name="DOI" value="10.17487/RFC7836"/>
</reference>
<reference anchor="RFC7919" target="https://www.rfc-editor.org/info/rfc7
919" quoteTitle="true" derivedAnchor="RFC7919">
<front>
<title>Negotiated Finite Field Diffie-Hellman Ephemeral Parameters f
or Transport Layer Security (TLS)</title>
<author initials="D." surname="Gillmor" fullname="D. Gillmor">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="August"/>
<abstract>
<t indent="0">Traditional finite-field-based Diffie-Hellman (DH) k
ey exchange during the Transport Layer Security (TLS) handshake suffers from a n
umber of security, interoperability, and efficiency shortcomings. These shortcom
ings arise from lack of clarity about which DH group parameters TLS servers shou
ld offer and clients should accept. This document offers a solution to these sh
ortcomings for compatible peers by using a section of the TLS "Supported Groups
Registry" (renamed from "EC Named Curve Registry" by this document) to establish
common finite field DH parameters with known structure and a mechanism for peer
s to negotiate support for these groups.</t>
<t indent="0">This document updates TLS versions 1.0 (RFC 2246), 1
.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptograph
y (ECC) extensions (RFC 4492).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7919"/>
<seriesInfo name="DOI" value="10.17487/RFC7919"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8422" target="https://www.rfc-editor.org/info/rfc8
422" quoteTitle="true" derivedAnchor="RFC8422">
<front>
<title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
Layer Security (TLS) Versions 1.2 and Earlier</title>
<author initials="Y." surname="Nir" fullname="Y. Nir">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Josefsson" fullname="S. Josefsson">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Pegourie-Gonnard" fullname="M. Pegour
ie-Gonnard">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document describes key exchange algorithms base
d on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) pr
otocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-
Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Cur
ve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algor
ithm (EdDSA) as authentication mechanisms.</t>
<t indent="0">This document obsoletes RFC 4492.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8422"/>
<seriesInfo name="DOI" value="10.17487/RFC8422"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" quoteTitle="true" derivedAnchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Transport
Layer Security (TLS) protocol. TLS allows client/server applications to commun
icate over the Internet in a way that is designed to prevent eavesdropping, tamp
ering, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements fo
r TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8645" target="https://www.rfc-editor.org/info/rfc8
645" quoteTitle="true" derivedAnchor="RFC8645">
<front>
<title>Re-keying Mechanisms for Symmetric Keys</title>
<author initials="S." surname="Smyshlyaev" fullname="S. Smyshlyaev"
role="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="August"/>
<abstract>
<t indent="0">A certain maximum amount of data can be safely encry
pted when encryption is performed under a single key. This amount is called the
"key lifetime". This specification describes a variety of methods for increasi
ng the lifetime of symmetric keys. It provides two types of re-keying mechanism
s based on hash functions and block ciphers that can be used with modes of opera
tions such as CTR, GCM, CBC, CFB, and OMAC.</t>
<t indent="0">This document is a product of the Crypto Forum Resea
rch Group (CFRG) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8645"/>
<seriesInfo name="DOI" value="10.17487/RFC8645"/>
</reference>
<reference anchor="RFC8891" target="https://www.rfc-editor.org/info/rfc8
891" quoteTitle="true" derivedAnchor="RFC8891">
<front>
<title>GOST R 34.12-2015: Block Cipher "Magma"</title>
<author initials="V." surname="Dolmatov" fullname="V. Dolmatov" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Baryshkov" fullname="D. Baryshkov">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="September"/>
<abstract>
<t indent="0">In addition to a new cipher with a block length of n
=128 bits (referred to as "Kuznyechik" and described in RFC 7801), Russian Feder
al standard GOST R 34.12-2015 includes an updated version of the block cipher wi
th a block length of n=64 bits and key length of k=256 bits, which is also refer
red to as "Magma". The algorithm is an updated version of an older block cipher
with a block length of n=64 bits described in GOST 28147-89 (RFC 5830). This doc
ument is intended to be a source of information about the updated version of the
64-bit cipher. It may facilitate the use of the block cipher in Internet applic
ations by providing information for developers and users of the GOST 64-bit ciph
er with the revised version of the cipher for encryption and decryption.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8891"/>
<seriesInfo name="DOI" value="10.17487/RFC8891"/>
</reference>
</references>
<references pn="section-12.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="CMAC" target="https://www.nist.gov/publications/recom
mendation-block-cipher-modes-operation-cmac-mode-authentication-0" quoteTitle="t
rue" derivedAnchor="CMAC">
<front>
<title>Recommendation for Block Cipher Modes of Operation: The CMAC
Mode for Authentication</title>
<author surname="Dworkin" initials="M." fullname="Morris Dworkin"/>
<date year="2016" month="October"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-38B"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38B"/>
</reference>
<reference anchor="I-D.smyshlyaev-tls13-gost-suites" quoteTitle="true" t
arget="https://datatracker.ietf.org/doc/html/draft-smyshlyaev-tls13-gost-suites-
05" derivedAnchor="DraftGostTLS13">
<front>
<title>GOST Cipher Suites for Transport Layer Security (TLS) Protoco
l Version 1.3</title>
<author fullname="Stanislav Smyshlyaev">
<organization showOnFrontPage="true">CryptoPro</organization>
</author>
<author fullname="Evgeny Alekseev">
<organization showOnFrontPage="true">CryptoPro</organization>
</author>
<author fullname="Ekaterina Griboedova">
<organization showOnFrontPage="true">CryptoPro</organization>
</author>
<author fullname="Alexandra Babueva">
<organization showOnFrontPage="true">CryptoPro</organization>
</author>
<author fullname="Lidiia Nikiforova">
<organization showOnFrontPage="true">CryptoPro</organization>
</author>
<date month="December" day="10" year="2021"/>
<abstract>
<t indent="0"> The purpose of this document is to make the Russi
an cryptographic
standards available to the Internet community for their
implementation in the Transport Layer Security (TLS) Protocol Version
1.3.
<reference anchor="GOST3413-2015"> This specification defines four new cipher suites, seven new
<front> signature schemes and a key exchange mechanism for the TLS 1.3
<title> protocol, that are based on Russian cryptographic standards (called
Information technology. Cryptographic data security. Modes o GOST algorithms). Additionally, this document specifies a profile of
f operation for block ciphers TLS 1.3 with GOST algorithms so that implementers can produce
</title> interoperable implementations. This document does not imply IETF
<author> endorsement of the cipher suites, signature schemes key exchange
<organization> mechanism.
Federal Agency on Technical Regulating and Metrology
</organization>
</author>
<date year="2015"/>
</front>
<seriesInfo name="GOST R" value="34.13-2015"/>
</reference>
<reference anchor="R-1323565.1.024-2019"> </t>
<front> </abstract>
<title> </front>
Information technology. Cryptographic data security. Ell <seriesInfo name="Internet-Draft" value="draft-smyshlyaev-tls13-gost-s
iptic curve parameters for the cryptographic algorithms and protocols uites-05"/>
</title> <format type="TXT" target="https://www.ietf.org/archive/id/draft-smysh
<author> lyaev-tls13-gost-suites-05.txt"/>
<organization> <refcontent>Work in Progress</refcontent>
Federal Agency on Technical Regulating and Metrology </reference>
</organization> <reference anchor="GOST3413-2015" quoteTitle="true" derivedAnchor="GOST3
</author> 413-2015">
<date year="2019"/> <front>
</front> <title>Information technology. Cryptographic data security. Modes of
<seriesInfo name="R" value="1323565.1.024-2019"/> operation for block ciphers</title>
</reference> <author>
<organization showOnFrontPage="true">Federal Agency on Technical R
egulating and Metrology</organization>
</author>
<date year="2015"/>
</front>
<seriesInfo name="GOST R" value="34.13-2015"/>
</reference>
<reference anchor="IK2003" quoteTitle="true" target="https://doi.org/10.
1007/978-3-540-39887-5_11" derivedAnchor="IK2003">
<front>
<title>OMAC: One-Key CBC MAC</title>
<author initials="T." surname="Iwata" fullname="Tetsu Iwata"/>
<author initials="K." surname="Kurosawa" fullname="Kaoru Kurosawa"/>
<date year="2003"/>
</front>
<seriesInfo name="DOI" value="10.1007/978-3-540-39887-5_11"/>
<refcontent>FSE 2003</refcontent>
<refcontent>Lecture Notes in Computer Science, Vol. 2887</refcontent>
</reference>
<reference anchor="MODES" target="https://csrc.nist.gov/publications/det
ail/sp/800-38a/final" quoteTitle="true" derivedAnchor="MODES">
<front>
<title>Recommendation for Block Cipher Modes of Operation: Methods a
nd Techniques</title>
<author initials="M." surname="Dworkin" fullname="Morris Dworkin"/>
<date year="2001" month="December"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-38A"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/>
</reference>
<reference anchor="R-1323565.1.024-2019" quoteTitle="true" derivedAnchor
="R-1323565.1.024-2019">
<front>
<title>Information technology. Cryptographic data security. Elliptic
curve parameters for the cryptographic algorithms and protocols</title>
<author>
<organization showOnFrontPage="true">Federal Agency on Technical R
egulating and Metrology</organization>
</author>
<date year="2019" month="January"/>
</front>
<seriesInfo name="R" value="1323565.1.024-2019"/>
</reference>
<reference anchor="I-D.ietf-tls-rfc8446bis" quoteTitle="true" target="ht
tps://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8446bis-03" derivedAnchor=
"RFC8446bis">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="Eric Rescorla">
<organization showOnFrontPage="true">Mozilla</organization>
</author>
<date month="October" day="25" year="2021"/>
<abstract>
<t indent="0"> This document specifies version 1.3 of the Transp
ort Layer Security
(TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery.
<reference anchor="MODES"> This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077,
<front> 5246, and 6961. This document also specifies new requirements for
<title> TLS 1.2 implementations.
Recommendation for Block Cipher Modes of Operation: Meth
ods and Techniques
</title>
<author>
<organization>
Dworkin, M.
</organization>
</author>
<date year="2001" month="December"/>
</front>
<seriesInfo name="NIST Special Publication " value="800-38A"/>
</reference>
<reference anchor="DraftGostTLS13" target="https://tools.ietf.org/ht
ml/draft-smyshlyaev-tls13-gost-suites-04">
<front>
<title>
GOST Cipher Suites for Transport Layer Security (TLS) Pr
otocol Version 1.3
</title>
<author initials="S." surname="Smyshlyaev" fullname="S. Smys
hlyaev">
<organization> CryptoPro </organization>
</author>
<author initials="E." surname="Alekseev" fullname="E. Alekse
ev">
<organization> CryptoPro </organization>
</author>
<author initials="E." surname="Griboedova" fullname="E. Grib
oedova">
<organization> CryptoPro </organization>
</author>
<author initials="A." surname="Babueva" fullname="A. Babueva
">
<organization> CryptoPro </organization>
</author>
<date year="2021"/>
</front>
</reference>
</references>
<section anchor="Appendix" title="Test Examples"> </t>
<section title ="Test Examples for CTR_OMAC cipher suites"> </abstract>
<section title ="TLSTREE Examples"> </front>
<section title ="TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC ciphe <seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-03"
rsuite"> />
<t> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
<figure> tls-rfc8446bis-03.txt"/>
<artwork> <refcontent>Work in Progress</refcontent>
<![CDATA[ </reference>
</references>
</references>
<section anchor="Appendix" numbered="true" toc="include" removeInRFC="false"
pn="section-appendix.a">
<name slugifiedName="name-test-examples">Test Examples</name>
<section numbered="true" toc="include" removeInRFC="false" pn="section-app
endix.a.1">
<name slugifiedName="name-test-examples-for-ctr_omac-">Test Examples for
CTR_OMAC Cipher Suites</name>
<section numbered="true" toc="include" removeInRFC="false" pn="section-a
ppendix.a.1.1">
<name slugifiedName="name-tlstree-examples">TLSTREE Examples</name>
<section numbered="true" toc="include" removeInRFC="false" pn="section
-appendix.a.1.1.1">
<name slugifiedName="name-tls_gostr341112_256_with_ma">TLS_GOSTR3411
12_256_WITH_MAGMA_CTR_OMAC Cipher Suite</name>
<sourcecode type="test-vectors" markers="false" pn="section-appendix
.a.1.1.1-1">
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC
*********************************************** ***********************************************
Root Key K_root: Root Key K_root:
00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A
11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00
seqnum = 0 seqnum = 0
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38
17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D
seqnum = 4095 seqnum = 4095
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38
17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D
seqnum = 4096 seqnum = 4096
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
FB 30 EE 53 CF CF 89 D7 48 FC 0C 72 EF 16 0B 8B FB 30 EE 53 CF CF 89 D7 48 FC 0C 72 EF 16 0B 8B
53 CB BB FD 03 12 82 B0 26 21 4A B2 E0 77 58 FF 53 CB BB FD 03 12 82 B0 26 21 4A B2 E0 77 58 FF
seqnum = 33554431 seqnum = 33554431
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
B8 5B 36 DC 22 82 32 6B C0 35 C5 72 DC 93 F1 8D B8 5B 36 DC 22 82 32 6B C0 35 C5 72 DC 93 F1 8D
83 AA 01 74 F3 94 20 9A 51 3B B3 74 DC 09 35 AE 83 AA 01 74 F3 94 20 9A 51 3B B3 74 DC 09 35 AE
seqnum = 33554432 seqnum = 33554432
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
3F EA 59 38 DA 2B F8 DD C4 7E C1 DC 55 61 89 66 3F EA 59 38 DA 2B F8 DD C4 7E C1 DC 55 61 89 66
79 02 BE 42 0D F4 C3 7D AF 21 75 3B CB 1D C7 F3 79 02 BE 42 0D F4 C3 7D AF 21 75 3B CB 1D C7 F3
The resulting key from Divers 3: The resulting key from Divers_3:
0F D7 C0 9E FD F8 E8 15 73 EE CC F8 6E 4B 95 E3 0F D7 C0 9E FD F8 E8 15 73 EE CC F8 6E 4B 95 E3
AF 7F 34 DA B1 17 7C FD 7D B9 7B 6D A9 06 40 8A AF 7F 34 DA B1 17 7C FD 7D B9 7B 6D A9 06 40 8A
seqnum = 274877906943 seqnum = 274877906943
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
AB F3 A5 37 98 3A 1B 98 40 06 6D E6 8A 49 BF 25 AB F3 A5 37 98 3A 1B 98 40 06 6D E6 8A 49 BF 25
97 7E E5 C3 F5 2D 33 3E 3C 22 0F 1D 15 C5 08 93 97 7E E5 C3 F5 2D 33 3E 3C 22 0F 1D 15 C5 08 93
The resulting key from Divers 3: The resulting key from Divers_3:
48 0F 99 72 BA F2 5D 4C 36 9A 96 AF 91 BC A4 55 48 0F 99 72 BA F2 5D 4C 36 9A 96 AF 91 BC A4 55
3F 79 D8 F0 C5 61 8B 19 FD 44 CF DC 57 FA 37 33 3F 79 D8 F0 C5 61 8B 19 FD 44 CF DC 57 FA 37 33
seqnum = 274877906944 seqnum = 274877906944
First level key from Divers_1: First-level key from Divers_1:
15 60 0D 9E 8F A6 85 54 CF 15 2D C7 4F BC 42 51 15 60 0D 9E 8F A6 85 54 CF 15 2D C7 4F BC 42 51
17 B0 3E 09 76 BB 28 EA 98 24 C3 B7 0F 28 CB D8 17 B0 3E 09 76 BB 28 EA 98 24 C3 B7 0F 28 CB D8
Second level key from Divers_2: Second-level key from Divers_2:
6C C2 8E B0 93 24 72 12 5C 7A D3 F8 09 73 B3 C8 6C C2 8E B0 93 24 72 12 5C 7A D3 F8 09 73 B3 C8
C4 13 7D A5 73 BC 17 1A 24 ED D4 A3 71 F1 F8 73 C4 13 7D A5 73 BC 17 1A 24 ED D4 A3 71 F1 F8 73
The resulting key from Divers 3: The resulting key from Divers_3:
25 28 C1 C6 A8 F0 92 7B F2 BE 27 BB 78 D2 7F 21 25 28 C1 C6 A8 F0 92 7B F2 BE 27 BB 78 D2 7F 21
46 D6 55 93 B0 C7 17 3A 06 CB 9D 88 DF 92 32 65 46 D6 55 93 B0 C7 17 3A 06 CB 9D 88 DF 92 32 65
</sourcecode>
]]> </section>
</artwork> <section numbered="true" toc="include" removeInRFC="false" pn="section
</figure> -appendix.a.1.1.2">
</t> <name slugifiedName="name-tls_gostr341112_256_with_ku">TLS_GOSTR3411
</section> 12_256_WITH_KUZNYECHIK_CTR_OMAC Cipher Suite</name>
<section title ="TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC <sourcecode type="test-vectors" markers="false" pn="section-appendix
ciphersuite"> .a.1.1.2-1">
<t>
<figure>
<artwork>
<![CDATA[
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC
*********************************************** ***********************************************
Root Key K_root: Root Key K_root:
00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A
11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00
seqnum = 0 seqnum = 0
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38
17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D
seqnum = 63 seqnum = 63
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38
17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D
seqnum = 64 seqnum = 64
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
AE BE 1E F4 18 71 3B F0 44 B9 FC D9 E5 72 D4 37 AE BE 1E F4 18 71 3B F0 44 B9 FC D9 E5 72 D4 37
FB 38 B5 D8 29 56 7A 6F 79 18 39 6D 9F 4E 09 6B FB 38 B5 D8 29 56 7A 6F 79 18 39 6D 9F 4E 09 6B
seqnum = 524287 seqnum = 524287
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F 51 37 D5 C4 A6 E6 BE 42 C4 40 D1 0A 95 EE A0 7F
08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4 08 9E 74 0D 38 90 EB 52 65 2C 0C B9 3F 20 7B B4
The resulting key from Divers 3: The resulting key from Divers_3:
6F 18 D4 00 3E A2 CB 30 F5 FE C1 93 A2 34 F0 7D 6F 18 D4 00 3E A2 CB 30 F5 FE C1 93 A2 34 F0 7D
7C 43 94 98 7F 50 75 8D E2 2B 22 0D 8A 10 51 06 7C 43 94 98 7F 50 75 8D E2 2B 22 0D 8A 10 51 06
seqnum = 524288 seqnum = 524288
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
F6 59 EB 85 EE BD 2A 8D CC 1B B3 F7 C6 00 57 FF F6 59 EB 85 EE BD 2A 8D CC 1B B3 F7 C6 00 57 FF
6D 33 B6 0F 74 65 DD 42 B5 11 2C F3 A6 B1 AB 66 6D 33 B6 0F 74 65 DD 42 B5 11 2C F3 A6 B1 AB 66
The resulting key from Divers 3: The resulting key from Divers_3:
E5 4B 16 41 5B 3B 66 3E 78 0B 06 2D 24 F7 36 C4 E5 4B 16 41 5B 3B 66 3E 78 0B 06 2D 24 F7 36 C4
49 54 63 C3 A8 91 E1 FA 46 F7 AE 99 FF F9 F3 78 49 54 63 C3 A8 91 E1 FA 46 F7 AE 99 FF F9 F3 78
seqnum = 4294967295 seqnum = 4294967295
First level key from Divers_1: First-level key from Divers_1:
F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1 F3 55 89 F0 9B F8 01 B1 CA 11 42 73 B9 5F D6 C1
39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42 39 2E 78 F9 FB 81 4D A0 5A 7C CA 08 9E C8 65 42
Second level key from Divers_2: Second-level key from Divers_2:
F4 BC 10 1A BB 68 86 2A 8C E3 1E A0 0D DF A7 FE F4 BC 10 1A BB 68 86 2A 8C E3 1E A0 0D DF A7 FE
B8 29 10 F1 24 F4 B1 E2 9E A8 3B E0 06 C2 26 8D B8 29 10 F1 24 F4 B1 E2 9E A8 3B E0 06 C2 26 8D
The resulting key from Divers 3: The resulting key from Divers_3:
CF 60 09 04 C7 1E 7B 88 A4 9A C8 E2 45 77 4B 3D CF 60 09 04 C7 1E 7B 88 A4 9A C8 E2 45 77 4B 3D
BE ED FB 81 DE 9A 0E 2F 4E 46 C3 56 07 BC 2F 04 BE ED FB 81 DE 9A 0E 2F 4E 46 C3 56 07 BC 2F 04
seqnum = 4294967296 seqnum = 4294967296
First level key from Divers_1: First-level key from Divers_1:
55 CC 95 E0 D1 FB 54 85 AF 8E F6 9A CD 72 B2 32 55 CC 95 E0 D1 FB 54 85 AF 8E F6 9A CD 72 B2 32
79 7C D2 E8 5D 86 CD FD 1D E5 5B D1 FA 14 37 78 79 7C D2 E8 5D 86 CD FD 1D E5 5B D1 FA 14 37 78
Second level key from Divers_2: Second-level key from Divers_2:
72 16 91 E1 01 C4 28 96 A6 40 AE 18 3F BB 44 5B 72 16 91 E1 01 C4 28 96 A6 40 AE 18 3F BB 44 5B
76 37 9C 57 E1 FD 8A 7D 49 A6 23 E4 23 8C 0E 1D 76 37 9C 57 E1 FD 8A 7D 49 A6 23 E4 23 8C 0E 1D
The resulting key from Divers 3: The resulting key from Divers_3:
16 18 0B 24 64 54 00 B8 36 14 38 37 D8 6A AC 93 16 18 0B 24 64 54 00 B8 36 14 38 37 D8 6A AC 93
95 2A E3 EB 82 44 D5 EC 2A B0 2C FF 30 78 11 38 95 2A E3 EB 82 44 D5 EC 2A B0 2C FF 30 78 11 38
</sourcecode>
]]> </section>
</artwork> </section>
</figure> <section numbered="true" toc="include" removeInRFC="false" pn="section-a
</t> ppendix.a.1.2">
</section> <name slugifiedName="name-record-examples">Record Examples</name>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section
<section title ="Record Examples"> -appendix.a.1.2.1">
<section title ="TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC ciphers <name slugifiedName="name-tls_gostr341112_256_with_mag">TLS_GOSTR341
uite"> 112_256_WITH_MAGMA_CTR_OMAC Cipher Suite</name>
<t> <sourcecode type="test-vectors" markers="false" pn="section-appendix
<figure> .a.1.2.1-1">
<artwork>
<![CDATA[
TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC
******************************************************** ********************************************************
It is assumed that during Handshake following keys were established: It is assumed that the following keys were established
during handshake:
- MAC key: - MAC key:
00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A
00010: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 00010: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00
- Encryption key: - Encryption key:
00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11
00010: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 00010: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22
- IV: - IV:
00000: 00 00 00 00 00000: 00 00 00 00
--------------------------------------------------------- ---------------------------------------------------------
skipping to change at line 2102 skipping to change at line 2682
TLSCiphertext: TLSCiphertext:
00000: 17 03 03 08 08 99 95 26 07 03 47 1D ED A2 E6 55 00000: 17 03 03 08 08 99 95 26 07 03 47 1D ED A2 E6 55
00010: B6 B3 93 83 5E 33 8B 1E D0 0E DD 22 47 A2 FB 88 00010: B6 B3 93 83 5E 33 8B 1E D0 0E DD 22 47 A2 FB 88
00020: FB B7 A8 94 80 62 08 8A F3 2C AE B6 AA 2C 4F 2A 00020: FB B7 A8 94 80 62 08 8A F3 2C AE B6 AA 2C 4F 2A
. . . . . .
007D0: 7F 0B 24 61 E7 5F E1 06 34 B8 4D C5 70 35 72 5A 007D0: 7F 0B 24 61 E7 5F E1 06 34 B8 4D C5 70 35 72 5A
007E0: CA 4F 0C BC A9 B0 6C B9 F7 6F BD 2F 80 46 2B 8D 007E0: CA 4F 0C BC A9 B0 6C B9 F7 6F BD 2F 80 46 2B 8D
007F0: 77 5E BD 41 6F 63 41 39 AC 89 C2 ED 3D F1 9F E2 007F0: 77 5E BD 41 6F 63 41 39 AC 89 C2 ED 3D F1 9F E2
00800: 4E F8 C0 5A A8 90 93 1B 01 86 FD 7D DF 00800: 4E F8 C0 5A A8 90 93 1B 01 86 FD 7D DF
</sourcecode>
]]> </section>
</artwork> <section numbered="true" toc="include" removeInRFC="false" pn="section
</figure> -appendix.a.1.2.2">
</t> <name slugifiedName="name-tls_gostr341112_256_with_kuz">TLS_GOSTR341
</section> 112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher Suite</name>
<section title ="TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC ci <sourcecode type="test-vectors" markers="false" pn="section-appendix
phersuite"> .a.1.2.2-1">
<t>
<figure>
<artwork>
<![CDATA[
TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC
*********************************************** ***********************************************
It is assumed that during Handshake following keys were established: It is assumed that the following keys were established
during handshake:
- MAC key: - MAC key:
00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A
00010: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 00010: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00
- Encryption key: - Encryption key:
00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11
00010: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 00010: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22
- IV: - IV:
00000: 00 00 00 00 00 00 00 00 00000: 00 00 00 00 00 00 00 00
skipping to change at line 2181 skipping to change at line 2756
. . . . . .
00FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01000: 00 00 00 00 00 01000: 00 00 00 00 00
K_MAC_63: K_MAC_63:
00000: 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38 00000: 19 A7 6E D3 0F 4D 6D 1F 5B 72 63 EC 49 1A D8 38
00010: 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D 00010: 17 C0 B5 7D 8A 03 56 12 71 40 FB 4F 74 25 49 4D
Mac value: MAC value:
00000: 98 46 27 61 D0 26 24 4A 2C 0B 7D 1B CC CB E7 B0 00000: 98 46 27 61 D0 26 24 4A 2C 0B 7D 1B CC CB E7 B0
K_ENC_63: K_ENC_63:
00000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79 00000: 58 AF BE 9A 4C 31 98 AA AB AA 26 92 C4 19 F1 79
00010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56 00010: 7C 9B 92 DE B3 CC 74 46 B3 63 57 71 13 F0 FB 56
IV_63: IV_63:
00000: 00 00 00 00 00 00 00 3F 00000: 00 00 00 00 00 00 00 3F
TLSCiphertext: TLSCiphertext:
skipping to change at line 2227 skipping to change at line 2802
. . . . . .
01FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01FD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01FE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01FF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02000: 00 00 00 00 00 02000: 00 00 00 00 00
K_MAC_64: K_MAC_64:
00000: AE BE 1E F4 18 71 3B F0 44 B9 FC D9 E5 72 D4 37 00000: AE BE 1E F4 18 71 3B F0 44 B9 FC D9 E5 72 D4 37
00010: FB 38 B5 D8 29 56 7A 6F 79 18 39 6D 9F 4E 09 6B 00010: FB 38 B5 D8 29 56 7A 6F 79 18 39 6D 9F 4E 09 6B
Mac value: MAC value:
00000: EA C3 97 87 84 2B 1D BD 60 80 CC 3F BF AE 5C 2F 00000: EA C3 97 87 84 2B 1D BD 60 80 CC 3F BF AE 5C 2F
K_ENC_64: K_ENC_64:
00000: 64 F5 5A FC 37 A1 74 D9 53 3E 70 8B CD 14 FA 4A 00000: 64 F5 5A FC 37 A1 74 D9 53 3E 70 8B CD 14 FA 4A
00010: EE C3 7B C0 E3 2B A4 99 01 B4 66 9E 96 A6 3D 96 00010: EE C3 7B C0 E3 2B A4 99 01 B4 66 9E 96 A6 3D 96
IV_64: IV_64:
00000: 00 00 00 00 00 00 00 40 00000: 00 00 00 00 00 00 00 40
TLSCiphertext: TLSCiphertext:
00000: 17 03 03 20 10 E6 66 BB 98 AC 5B 0F 39 31 D8 55 00000: 17 03 03 20 10 E6 66 BB 98 AC 5B 0F 39 31 D8 55
00010: 1B 93 36 85 96 EE F0 EB A8 26 9C B8 BD AA E7 EB 00010: 1B 93 36 85 96 EE F0 EB A8 26 9C B8 BD AA E7 EB
00020: 80 C8 30 D7 5A B7 D4 6C 25 06 DC 8B 83 E1 F2 D3 00020: 80 C8 30 D7 5A B7 D4 6C 25 06 DC 8B 83 E1 F2 D3
. . . . . .
01FE0: B3 02 67 2C CB 02 86 CD 40 48 FB D5 38 1A 65 55 01FE0: B3 02 67 2C CB 02 86 CD 40 48 FB D5 38 1A 65 55
01FF0: 26 11 25 51 01 4F A8 ED F5 C2 1B 7D 1D B3 9D 6B 01FF0: 26 11 25 51 01 4F A8 ED F5 C2 1B 7D 1D B3 9D 6B
02000: AD EC 0D 7C 07 05 34 8B 5C 55 6C 4D 50 81 69 1A 02000: AD EC 0D 7C 07 05 34 8B 5C 55 6C 4D 50 81 69 1A
02010: A9 EC 36 F8 B5 02010: A9 EC 36 F8 B5
</sourcecode>
]]> </section>
</artwork> </section>
</figure> <section numbered="true" toc="include" removeInRFC="false" pn="section-a
</t> ppendix.a.1.3">
</section> <name slugifiedName="name-handshake-examples">Handshake Examples</name
</section> >
<t indent="0" pn="section-appendix.a.1.3-1">
<section title ="Handshake Examples"> The ClientHello.extensions and the ServerHello.extensions f
<t> ields contain the extended_main_secret extension (see <xref target="RFC7627" for
The ClientHello.extensions and the ServerHello.extensions f mat="default" sectionFormat="of" derivedContent="RFC7627"/>) and the renegotiati
ields contain the extended_master_secret extension (see <xref target="RFC7627"/> on_info extension (see <xref target="RFC5746" format="default" sectionFormat="of
) and the renegotiation_info extension (see <xref target="RFC5746"/>) " derivedContent="RFC5746"/>)
in the following examples. in the following examples.
</t> </t>
<section title ="TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC ciphers <section numbered="true" toc="include" removeInRFC="false" pn="section
uite"> -appendix.a.1.3.1">
<t> <name slugifiedName="name-tls_gostr341112_256_with_magm">TLS_GOSTR34
<figure> 1112_256_WITH_MAGMA_CTR_OMAC Cipher Suite</name>
<artwork> <sourcecode type="test-vectors" markers="false" pn="section-appendix
<![CDATA[ .a.1.3.1-1">
Server certificate curve OID: Server certificate curve OID:
id-GostR3410-2001-CryptoPro-A-ParamSet, "1.2.643.2.2.35.1" id-GostR3410-2001-CryptoPro-A-ParamSet, "1.2.643.2.2.35.1"
Server public key Q_s: Server public key Q_s:
x = 0x6531D4A72E655BFC9DFB94293B260702 x = 0x6531D4A72E655BFC9DFB94293B260702
82FABF10D5C49B7366148C60E0BF8167 82FABF10D5C49B7366148C60E0BF8167
y = 0x37F8CC71DC5D917FC4A66F7826E72750 y = 0x37F8CC71DC5D917FC4A66F7826E72750
8270B4FFC266C26CD4363E77B553A5B8 8270B4FFC266C26CD4363E77B553A5B8
skipping to change at line 2328 skipping to change at line 2897
signature: signature:
41 41
Extension: /* renegotiation_info */ Extension: /* renegotiation_info */
extension_type: FF01 extension_type: FF01
extension_data: extension_data:
length: 0001 length: 0001
vector: vector:
renegotiated_connection: renegotiated_connection:
length: 00 length: 00
vector: -- vector: --
Extension: /* extended_master_secret */ Extension: /* extended_main_secret */
extension_type: 0017 extension_type: 0017
extension_data: extension_data:
length: 0000 length: 0000
vector: -- vector: --
00000: 01 00 00 40 03 03 93 3E A2 1E C3 80 2A 56 15 50 00000: 01 00 00 40 03 03 93 3E A2 1E C3 80 2A 56 15 50
00010: EC 78 D6 ED 51 AC 24 39 D7 E7 49 C3 1B C3 A3 45 00010: EC 78 D6 ED 51 AC 24 39 D7 E7 49 C3 1B C3 A3 45
00020: 61 65 88 96 84 CA 00 00 04 C1 00 C1 01 01 00 00 00020: 61 65 88 96 84 CA 00 00 04 C1 00 C1 01 01 00 00
00030: 13 00 0D 00 06 00 04 08 40 08 41 FF 01 00 01 00 00030: 13 00 0D 00 06 00 04 08 40 08 41 FF 01 00 01 00
00040: 00 17 00 00 00040: 00 17 00 00
skipping to change at line 2387 skipping to change at line 2956
length: 0009 length: 0009
vector: vector:
Extension: /* renegotiation_info */ Extension: /* renegotiation_info */
extension_type: FF01 extension_type: FF01
extension_data: extension_data:
length: 0001 length: 0001
vector: vector:
renegotiated_connection: renegotiated_connection:
length: 00 length: 00
vector: -- vector: --
Extension: /* extended_master_secret */ Extension: /* extended_main_secret */
extension_type: 0017 extension_type: 0017
extension_data: extension_data:
length: 0000 length: 0000
vector: -- vector: --
00000: 02 00 00 41 03 03 93 3E A2 1E 49 C3 1B C3 A3 45 00000: 02 00 00 41 03 03 93 3E A2 1E 49 C3 1B C3 A3 45
00010: 61 65 88 96 84 CA A5 57 6C E7 92 4A 24 F5 81 13 00010: 61 65 88 96 84 CA A5 57 6C E7 92 4A 24 F5 81 13
00020: 80 8D BD 9E F8 56 10 C3 80 2A 56 15 50 EC 78 D6 00020: 80 8D BD 9E F8 56 10 C3 80 2A 56 15 50 EC 78 D6
00030: ED 51 AC 24 39 D7 E7 C1 01 00 00 09 FF 01 00 01 00030: ED 51 AC 24 39 D7 E7 C1 01 00 00 09 FF 01 00 01
00040: 00 00 17 00 00 00040: 00 00 17 00 00
skipping to change at line 2904 skipping to change at line 3473
Record layer message: Record layer message:
type: 15 type: 15
version: version:
major: 03 major: 03
minor: 03 minor: 03
length: 000A length: 000A
fragment: 999468B49AC5B0DE512C fragment: 999468B49AC5B0DE512C
00000: 15 03 03 00 0A 99 94 68 B4 9A C5 B0 DE 51 2C 00000: 15 03 03 00 0A 99 94 68 B4 9A C5 B0 DE 51 2C
</sourcecode>
]]> </section>
</artwork> <section numbered="true" toc="include" removeInRFC="false" pn="section
</figure> -appendix.a.1.3.2">
</t> <name slugifiedName="name-tls_gostr341112_256_with_kuzn">TLS_GOSTR34
</section> 1112_256_WITH_KUZNYECHIK_CTR_OMAC Cipher Suite</name>
<section title ="TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC ci <sourcecode type="test-vectors" markers="false" pn="section-appendix
phersuite"> .a.1.3.2-1">
<t>
<figure>
<artwork>
<![CDATA[
Server certificate curve OID: Server certificate curve OID:
id-tc26-gost-3410-2012-512-paramSetC, "1.2.643.7.1.2.1.2.3" id-tc26-gost-3410-2012-512-paramSetC, "1.2.643.7.1.2.1.2.3"
Server public key Q_s: Server public key Q_s:
x = 0xF14589DA479AD972C66563669B3FF580 x = 0xF14589DA479AD972C66563669B3FF580
92E6A30A288BF447CD9FF6C3133E9724 92E6A30A288BF447CD9FF6C3133E9724
7A9706B267703C9B4E239F0D7C7E3310 7A9706B267703C9B4E239F0D7C7E3310
C22D2752B35BD2E4FD39B8F11DEB833A C22D2752B35BD2E4FD39B8F11DEB833A
y = 0xF305E95B36502D4E60A1059FB20AB30B y = 0xF305E95B36502D4E60A1059FB20AB30B
skipping to change at line 3000 skipping to change at line 3562
signature: signature:
41 41
Extension: /* renegotiation_info */ Extension: /* renegotiation_info */
extension_type: FF01 extension_type: FF01
extension_data: extension_data:
length: 0001 length: 0001
vector: vector:
renegotiated_connection: renegotiated_connection:
length: 00 length: 00
vector: -- vector: --
Extension: /* extended_master_secret */ Extension: /* extended_main_secret */
extension_type: 0017 extension_type: 0017
extension_data: extension_data:
length: 0000 length: 0000
vector: -- vector: --
00000: 01 00 00 40 03 03 93 3E A2 1E C3 80 2A 56 15 50 00000: 01 00 00 40 03 03 93 3E A2 1E C3 80 2A 56 15 50
00010: EC 78 D6 ED 51 AC 24 39 D7 E7 49 C3 1B C3 A3 45 00010: EC 78 D6 ED 51 AC 24 39 D7 E7 49 C3 1B C3 A3 45
00020: 61 65 88 96 84 CA 00 00 04 C1 00 C1 01 01 00 00 00020: 61 65 88 96 84 CA 00 00 04 C1 00 C1 01 01 00 00
00030: 13 00 0D 00 06 00 04 08 40 08 41 FF 01 00 01 00 00030: 13 00 0D 00 06 00 04 08 40 08 41 FF 01 00 01 00
00040: 00 17 00 00 00040: 00 17 00 00
skipping to change at line 3059 skipping to change at line 3621
length: 0009 length: 0009
vector: vector:
Extension: /* renegotiation_info */ Extension: /* renegotiation_info */
extension_type: FF01 extension_type: FF01
extension_data: extension_data:
length: 0001 length: 0001
vector: vector:
renegotiated_connection: renegotiated_connection:
length: 00 length: 00
vector: -- vector: --
Extension: /* extended_master_secret */ Extension: /* extended_main_secret */
extension_type: 0017 extension_type: 0017
extension_data: extension_data:
length: 0000 length: 0000
vector: -- vector: --
00000: 02 00 00 41 03 03 93 3E A2 1E 49 C3 1B C3 A3 45 00000: 02 00 00 41 03 03 93 3E A2 1E 49 C3 1B C3 A3 45
00010: 61 65 88 96 84 CA A5 57 6C E7 92 4A 24 F5 81 13 00010: 61 65 88 96 84 CA A5 57 6C E7 92 4A 24 F5 81 13
00020: 80 8D BD 9E F8 56 10 C3 80 2A 56 15 50 EC 78 D6 00020: 80 8D BD 9E F8 56 10 C3 80 2A 56 15 50 EC 78 D6
00030: ED 51 AC 24 39 D7 E7 C1 00 00 00 09 FF 01 00 01 00030: ED 51 AC 24 39 D7 E7 C1 00 00 00 09 FF 01 00 01
00040: 00 00 17 00 00 00040: 00 00 17 00 00
skipping to change at line 3790 skipping to change at line 4352
type: 15 type: 15
version: version:
major: 03 major: 03
minor: 03 minor: 03
length: 0012 length: 0012
fragment: EB62E5AB78BF2A4B678920A11027EC43 fragment: EB62E5AB78BF2A4B678920A11027EC43
0C3F 0C3F
00000: 15 03 03 00 12 EB 62 E5 AB 78 BF 2A 4B 67 89 20 00000: 15 03 03 00 12 EB 62 E5 AB 78 BF 2A 4B 67 89 20
00010: A1 10 27 EC 43 0C 3F 00010: A1 10 27 EC 43 0C 3F
]]> </sourcecode>
</artwork> </section>
</figure> </section>
</t> </section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-app
endix.a.2">
</section> <name slugifiedName="name-test-examples-for-cnt_imit-">Test Examples for
</section> CNT_IMIT Cipher Suites</name>
<section title ="Test Examples for CNT_IMIT cipher suites"> <section numbered="true" toc="include" removeInRFC="false" pn="section-a
<section title ="Record Examples"> ppendix.a.2.1">
<t> <name slugifiedName="name-record-examples-2">Record Examples</name>
<figure> <sourcecode type="test-vectors" markers="false" pn="section-appendix.a
<artwork> .2.1-1">
<![CDATA[ It is assumed that the following keys were established
It is assumed that during Handshake following keys were established: during handshake:
- MAC key: - MAC key:
00000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
- Encryption key: - Encryption key:
00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- IV: - IV:
00000: 00 00 00 00 00 00 00 00 00000: 00 00 00 00 00 00 00 00
skipping to change at line 3856 skipping to change at line 4414
MAC: MAC:
00000: f7 c3 8b 8a 00000: f7 c3 8b 8a
Ciphertext: Ciphertext:
00000: 17 03 03 08 04 cf aa 0c b4 2f a5 a4 7a 13 3d 73 00000: 17 03 03 08 04 cf aa 0c b4 2f a5 a4 7a 13 3d 73
00010: b9 f2 c0 b0 4f 8c a2 55 52 f8 56 bc be 6a 58 fa 00010: b9 f2 c0 b0 4f 8c a2 55 52 f8 56 bc be 6a 58 fa
.... ....
007f0: 3e e2 c7 6f a2 30 a0 44 be 21 dc 8e 1a 96 f9 a8 007f0: 3e e2 c7 6f a2 30 a0 44 be 21 dc 8e 1a 96 f9 a8
00804: 88 1f ad 83 45 96 96 84 47 00804: 88 1f ad 83 45 96 96 84 47
</sourcecode>
]]> </section>
</artwork> <section numbered="true" toc="include" removeInRFC="false" pn="section-a
</figure> ppendix.a.2.2">
</t> <name slugifiedName="name-handshake-examples-2">Handshake Examples</na
me>
</section> <t indent="0" pn="section-appendix.a.2.2-1">
The ClientHello.extensions and the ServerHello.extensions
<section title ="Handshake Examples"> fields contain the renegotiation_info extension (see <xref target="RFC5746" form
<t> at="default" sectionFormat="of" derivedContent="RFC5746"/>)
The ClientHello.extensions and the ServerHello.extensions
fields contain the renegotiation_info extension (see <xref target="RFC5746"/>)
in the following examples. in the following examples.
</t> </t>
<t> <sourcecode type="test-vectors" markers="false" pn="section-appendix.a
<figure> .2.2-2">
<artwork>
<![CDATA[
Server certificate curve OID: Server certificate curve OID:
id-tc26-gost-3410-12-512-paramSetA, "1.2.643.7.1.2.1.2.1" id-tc26-gost-3410-12-512-paramSetA, "1.2.643.7.1.2.1.2.1"
Server public key Q_s: Server public key Q_s:
x = 0x16DB0566C0278AC8204143994824236D x = 0x16DB0566C0278AC8204143994824236D
97F36A13D5433E990B2EAC859D2E9B7A 97F36A13D5433E990B2EAC859D2E9B7A
E054794655389158B8242923E3841B14 E054794655389158B8242923E3841B14
24FD89F221701C89D9A3BF6A9F946795 24FD89F221701C89D9A3BF6A9F946795
y = 0xD01E80DEC5BD23C8BC6B85F12BBB1635 y = 0xD01E80DEC5BD23C8BC6B85F12BBB1635
skipping to change at line 4480 skipping to change at line 5030
Record layer message: Record layer message:
type: 15 type: 15
version: version:
major: 03 major: 03
minor: 03 minor: 03
length: 0006 length: 0006
fragment: 117B57AD5FED fragment: 117B57AD5FED
00000: 15 03 03 00 06 11 7B 57 AD 5F ED 00000: 15 03 03 00 06 11 7B 57 AD 5F ED
</sourcecode>
]]>
</artwork>
</figure>
</t>
</section>
</section>
</section>
<section anchor="contributors" title="Contributors">
<t>
<list style="symbols">
<t>
Ekaterina Griboedova <vspace/>
CryptoPro <vspace/>
griboedova.e.s@gmail.com
</t>
<t>
Grigory Sedov<vspace />
CryptoPro<vspace />
sedovgk@cryptopro.ru
</t>
<t>
Dmitry Eremin-Solenikov <vspace />
Auriga <vspace />
dbaryshkov@gmail.com
</t>
<t>
Lidiia Nikiforova <vspace/>
CryptoPro <vspace/>
nikiforova@cryptopro.ru
</t>
</list>
</t>
</section>
<section title="Acknowledgments">
</section> </section>
</section>
</back> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f
alse" pn="section-appendix.b">
<name slugifiedName="name-contributors">Contributors</name>
<contact fullname="Ekaterina Griboedova">
<organization showOnFrontPage="true">CryptoPro</organization>
<address>
<email>griboedova.e.s@gmail.com</email>
</address>
</contact>
<contact fullname="Grigory Sedov">
<organization showOnFrontPage="true">CryptoPro</organization>
<address>
<email>sedovgk@cryptopro.ru</email>
</address>
</contact>
<contact fullname="Dmitry Eremin-Solenikov">
<organization showOnFrontPage="true">Auriga</organization>
<address>
<email>dbaryshkov@gmail.com</email>
</address>
</contact>
<contact fullname="Lidiia Nikiforova">
<organization showOnFrontPage="true">CryptoPro</organization>
<address>
<email>nikiforova@cryptopro.ru</email>
</address>
</contact>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.c">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Stanislav Smyshlyaev" initials="S." role="editor" surnam
e="Smyshlyaev">
<organization showOnFrontPage="true">CryptoPro</organization>
<address>
<postal>
<street>18, Suschevsky val</street>
<city>Moscow</city>
<code>127018</code>
<country>Russian Federation</country>
</postal>
<phone>+7 (495) 995-48-20</phone>
<email>svs@cryptopro.ru</email>
</address>
</author>
<author fullname="Dmitry Belyavskiy" initials="D." surname="Belyavskiy">
<organization showOnFrontPage="true">Cryptocom</organization>
<address>
<postal>
<street>14/2, Kedrova St.</street>
<city>Moscow</city>
<code>117218</code>
<country>Russian Federation</country>
</postal>
<email>beldmit@gmail.com</email>
</address>
</author>
<author fullname="Evgeny Alekseev" initials="E." surname="Alekseev">
<organization showOnFrontPage="true">CryptoPro</organization>
<address>
<postal>
<street>18, Suschevsky val</street>
<city>Moscow</city>
<code>127018</code>
<country>Russian Federation</country>
</postal>
<email>alekseev@cryptopro.ru</email>
</address>
</author>
</section>
</back>
</rfc> </rfc>
 End of changes. 162 change blocks. 
2015 lines changed or deleted 3178 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/