Skip to main content

ShangMi (SM) Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
draft-yang-tls-tls13-sm-suites-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8998.
Author Paul Yang
Last updated 2020-08-12 (Latest revision 2020-07-04)
RFC stream Independent Submission
Formats
IETF conflict review conflict-review-yang-tls-tls13-sm-suites, conflict-review-yang-tls-tls13-sm-suites, conflict-review-yang-tls-tls13-sm-suites, conflict-review-yang-tls-tls13-sm-suites, conflict-review-yang-tls-tls13-sm-suites, conflict-review-yang-tls-tls13-sm-suites, conflict-review-yang-tls-tls13-sm-suites
Additional resources
Stream ISE state In ISE Review
Revised I-D Needed
Consensus boilerplate Unknown
Document shepherd Eliot Lear
IESG IESG state Became RFC 8998 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to Adrian Farrel <rfc-ise@rfc-editor.org>
draft-yang-tls-tls13-sm-suites-04
TLS                                                              P. Yang
Internet-Draft                                            Ant Technology
Intended status: Informational                             July 04, 2020
Expires: January 5, 2021

 ShangMi (SM) Cipher Suites for Transport Layer Security (TLS) Protocol
                              Version 1.3
                   draft-yang-tls-tls13-sm-suites-04

Abstract

   This document specifies a set of cipher suites for the Transport
   Layer Security (TLS) protocol version 1.3 to support ShangMi (SM)
   cryptographic algorithms.

   The use of these cipher suites with TLSv1.3 is not endorsed by the
   IETF.  The SM cipher suites are becoming mandatory in China, and so
   this document provides a description of how to use the SM cipher
   suites with TLSv1.3 so that implementers can produce interworking
   implementations.

Status of This Memo

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

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

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

   This Internet-Draft will expire on January 5, 2021.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Yang                     Expires January 5, 2021                [Page 1]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  The SM Algorithms . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Supported Cipher Suites . . . . . . . . . . . . . . . . . . .   4
   3.  Cipher Suites Definitions . . . . . . . . . . . . . . . . . .   4
     3.1.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Authentication  . . . . . . . . . . . . . . . . . . . . .   4
       3.2.1.  SM2 Signature Scheme  . . . . . . . . . . . . . . . .   4
     3.3.  Key Exchange  . . . . . . . . . . . . . . . . . . . . . .   6
       3.3.1.  Hello Messages  . . . . . . . . . . . . . . . . . . .   6
       3.3.2.  CertificateRequest  . . . . . . . . . . . . . . . . .   7
       3.3.3.  Certificate . . . . . . . . . . . . . . . . . . . . .   7
       3.3.4.  CertificateVerify . . . . . . . . . . . . . . . . . .   7
     3.4.  Key Scheduling  . . . . . . . . . . . . . . . . . . . . .   7
     3.5.  Cipher  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.5.1.  AEAD_SM4_GCM  . . . . . . . . . . . . . . . . . . . .   8
       3.5.2.  AEAD_SM4_CCM  . . . . . . . . . . . . . . . . . . . .   9
     3.6.  Hash  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  13
     A.1.  SM4-GCM Test Vectors  . . . . . . . . . . . . . . . . . .  13
     A.2.  SM4-CCM Test Vectors  . . . . . . . . . . . . . . . . . .  13
   Appendix B.  Contributors . . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This document describes two new cipher suites for the Transport Layer
   Security (TLS) protocol version 1.3 (TLSv1.3, [RFC8446]).  The new
   cipher suites are (see also Section 2):

      CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 };
      CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 };

   These new cipher suites contain several ShangMi (SM) cryptographic
   algorithms that provide both authentication and confidentiality.  For

Yang                     Expires January 5, 2021                [Page 2]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

   a more detailed introduction to SM cryptographic algorithms, please
   read Section 1.1.  These cipher suites follow the TLSv1.3
   requirements.  Specifically, all the cipher suites mentioned in this
   document use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) as the
   key exchange scheme and use SM4 in either GCM (Galois/Counter Mode)
   mode or CCM (Counter with CBC-MAC) mode to meet the needs of TLSv1.3
   to have an AEAD (Authenticated Encryption with Associated Data)
   capable encryption algorithm.

   For the details about how these new cipher suites negotiate shared
   encryption keys and protect the record structure, please read
   Section 3.

   The cipher suites defined in this document are not recommended by the
   IETF.  The SM cipher suites are becoming mandatory in China, and so
   this document provides a description of how to use the SM cipher
   suites with TLSv1.3 so that implementers can produce interworking
   implementations.

1.1.  The SM Algorithms

   The new cipher suites defined in this document use several different
   SM cryptographic algorithms including SM2 for authentication, SM4 for
   encryption and SM3 as the hash function.

   SM2 is a set of elliptic curve based cryptographic algorithms
   including digital signature, public key encryption and key exchange
   scheme.  In this document, only the SM2 digital signature algorithm
   is involved, which has already been added to ISO/IEC 14888-3:2018
   [ISO-SM2] (as well as in [GBT.32918.2-2016]).  SM4 is a block cipher
   defined in [GBT.32907-2016] and now is being standardized by ISO to
   ISO/IEC 18033-3:2010 [ISO-SM4].  SM3 is a hash function which
   produces an output of 256 bits.  SM3 has already been accepted by ISO
   in ISO/IEC 10118-3:2018 [ISO-SM3], and also been described by
   [GBT.32905-2016].

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here, and indicate requirement levels for
   compliant TLSv1.3 implementations.

Yang                     Expires January 5, 2021                [Page 3]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

2.  Supported Cipher Suites

   The cipher suites defined here have the following identifiers:

      CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 };
      CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 };

   To accomplish a TLSv1.3 handshake, additional objects have been
   introduced along with the cipher suites as follows.

   The SM2 signature algorithm and SM3 hash function used in the
   Signature Algorithm extension defined in appendix-B.3.1.3 of
   [RFC8446]:

      SignatureScheme sm2sig_sm3 = { 0x0708 };

   The SM2 elliptic curve ID used in the Supported Groups extension
   defined in appendix-B.3.1.4 of [RFC8446]:

      NamedGroup curveSM2 = { 41 };

3.  Cipher Suites Definitions

3.1.  TLS Versions

   The new cpher suites defined in this document are only applicable to
   TLSv1.3.  Implementations of this document MUST NOT apply these
   cipher suites to any older versions of TLS.

3.2.  Authentication

3.2.1.  SM2 Signature Scheme

   All cipher suites defined in this document MUST use the SM2 signature
   algorithm as the authentication method when doing a TLSv1.3
   handshake.

   The SM2 signature is defined in [ISO-SM2].  SM2 signature algorithm
   is based on elliptic curves.  SM2 signature algorithm uses a fixed
   elliptic curve parameter set defined in [GBT.32918.5-2016].  This
   curve has the name curveSM2 and has been assigned the value 41 as
   shown in Section 4.  Unlike other elliptic curve based public key
   algorithms like ECDSA, SM2 MUST NOT select other elliptic curves.
   But it is acceptable to write test cases that use other elliptic
   curve parameter sets for SM2, take Annex F.14 of [ISO-SM2] as a
   reference.

Yang                     Expires January 5, 2021                [Page 4]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

   Implementations of the cipher suites defined in this document SHOULD
   conform to what [GBT.32918.5-2016] requires, that is to say, the only
   valid elliptic curve parameter for SM2 signature algorithm (a.k.a
   curveSM2) is defined as follows:

      curveSM2: a prime field of 256 bits

      y^2 = x^3 + ax + b

      p  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
           FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
      a  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
           FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
      b  = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
           F39789F5 15AB8F92 DDBCBD41 4D940E93
      n  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
           7203DF6B 21C6052B 53BBF409 39D54123
      Gx = 32C4AE2C 1F198119 5F990446 6A39C994
           8FE30BBF F2660BE1 715A4589 334C74C7
      Gy = BC3736A2 F4F6779C 59BDCEE3 6B692153
           D0A9877C C62A4740 02DF32E5 2139F0A0

   The SM2 signature algorithm requests an identifier value when
   generating or verifying a signature.  Implementations of this
   document MUST use the following ASCII string value as the SM2
   identifier when doing a TLSv1.3 key exchange:

      TLSv1.3+GM+Cipher+Suite

   Except if either a client or a server needs to verify the peer's SM2
   certificate contained in the Certificate message, then the following
   ASCII string value SHOULD be used as the SM2 identifier according to
   [GMT.0009-2012]:

      1234567812345678

   Expressed as octets, this is:

      0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38,
      0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38

   In practice, the SM2 identifier used in a certificate signature
   depends on the CA who signs that certificate.  CAs may choose values
   other than the ones mentioned above.  Implementations of this
   document SHOULD confirm this information by themselves.

Yang                     Expires January 5, 2021                [Page 5]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

3.3.  Key Exchange

3.3.1.  Hello Messages

   The new cipher suites defined in this document update the key
   exchange information in the Hello messages.  Implementations of these
   new ciphers suites MUST conform to the new requirements.

3.3.1.1.  ClientHello

   A TLSv1.3 client MUST include the new cipher suites in its
   'cipher_suites' array of the ClientHello structure defined in
   Section 4.1.2 of [RFC8446].

   Other requirements on the extensions of ClientHello message are:

   o  For the supported_groups extension, 'curveSM2' MUST be included;

   o  For the signature_algorithms extension, 'sm2sig_sm3' MUST be
      included;

   o  For the signature_algorithms_cert extension (if present),
      'sm2sig_sm3' MUST be included;

   o  For the key_share extension, a KeyShareEntry with SM2 related
      values MUST be added if the client wants to start a TLSv1.3 key
      negotiation using SM cipher suites.

3.3.1.2.  ServerHello

   If a TLSv1.3 server receives a ClientHello message containing the new
   cipher suites defined in this document, it MAY choose to use the new
   cipher suites.  If so, then the server MUST put one of the new cipher
   suites defined in this document into its ServerHello's
   'cipher_suites' array and eventually send it to the client side.

   A TLSv1.3 server's choice of what cipher suite to use depends on the
   configuration of the server.  For instance, a TLSv1.3 server may be
   configured to include the new cipher suites defined in this document,
   or it may not be.  Typical TLSv1.3 server applications also provide a
   mechanism that configures the cipher suite preference at server side.
   If a server is not configured to use the cipher suites defined in
   this document, it SHOULD choose another cipher suite in the list that
   the TLSv1.3 client provides; otherwise the server MUST abort the
   handshake with an "illegal_parameter" alert.

   The following extensions MUST conform to the new requirements:

Yang                     Expires January 5, 2021                [Page 6]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

   o  For the key_share extension, a KeyShareEntry with SM2 related
      values MUST be added if the server wants to start a TLSv1.3 key
      negotiation using SM cipher suites.

3.3.2.  CertificateRequest

   If a CertificateRequest message is sent by the server to require the
   client to send its certificate for authentication purposes, the
   following requirements MUST be fulfilled:

   o  The only valid signature algorithm present in
      'signature_algorithms' extension MUST be 'sm2sig_sm3'.  That is to
      say, if server chooses to use an SM cipher suite, the signature
      algorithm for client's certificate SHOULD only be SM2 and SM3
      capable ones.

3.3.3.  Certificate

   When a server sends the Certificate message containing the server
   certificate to the client side, several new rules are added that will
   affect the certificate selection:

   o  The public key in the certificate MUST be a valid SM2 public key.

   o  The signature algorithm used by the CA to sign current certificate
      MUST be 'sm2sig_sm3'.

   o  The certificate MUST be capable of signing, e.g., the
      digitalSignature bit of X.509's Key Usage extension is set.

3.3.4.  CertificateVerify

   In the certificateVerify message, the signature algorithm MUST be
   'sm2sig_sm3', indicating that the hash function MUST be SM3 and the
   signature algorithm MUST be SM2.

3.4.  Key Scheduling

   As described in Section 1.1, SM2 is actually a set of cryptographic
   algorithms including one key exchange protocol which defines methods
   such as key derivation function, etc.  In this document, SM2 key
   exchange protocol is not introduced and SHALL NOT be used in the key
   exchange steps defined in Section 3.3.  Implementations of this
   document MUST always conform to what TLSv1.3 [RFC8446] and its
   successors require about the key derivation and related methods.

Yang                     Expires January 5, 2021                [Page 7]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

3.5.  Cipher

   The new cipher suites introduced in this document add two new AEAD
   encryption algorithms, AEAD_SM4_GCM and AEAD_SM4_CCM, which stand for
   SM4 cipher in Galois/Counter mode and SM4 cipher [GBT.32907-2016] in
   Counter with CBC-MAC mode, respectively.

   This section defines the AEAD_SM4_GCM and AEAD_SM4_CCM AEAD
   algorithms in a style similar to what [RFC5116] used to define AEAD
   ciphers based on AES cipher.

3.5.1.  AEAD_SM4_GCM

   The AEAD_SM4_GCM authenticated encryption algorithm works as
   specified in [GCM], using SM4 as the block cipher, by providing the
   key, nonce, plaintext, and associated data to that mode of operation.
   An authentication tag conforming to the requirements of Section 5.2
   of TLSv1.3 [RFC8446] MUST be constructed by the details in the TLS
   record header.  The additional data input that forms the
   authentication tag MUST be the TLS record header.  The AEAD_SM4_GCM
   ciphertext is formed by appending the authentication tag provided as
   an output to the GCM encryption operation to the ciphertext that is
   output by that operation.  AEAD_SM4_GCM has four inputs: an SM4 key,
   an initialization vector (IV), a plaintext content, and optional
   additional authenticated data (AAD).  AEAD_SM4_GCM generates two
   outputs: a ciphertext and message authentication code (also called an
   authentication tag).  To have a common set of terms for AEAD_SM4_GCM
   and AEAD_SM4_CCM, the AEAD_SM4_GCM IV is referred to as a nonce in
   the remainder of this document.  A simple test vector of AEAD_SM4_GCM
   and AEAD_SM4_CCM is given in Appendix A of this document.

   The nonce is generated by the party performing the authenticated
   encryption operation.
   Within the scope of any authenticated-encryption key, the nonce value
   MUST be unique.  That is, the set of nonce values used with any given
   key MUST NOT contain any duplicates.  Using the same nonce for two
   different messages encrypted with the same key destroys the security
   properties of GCM mode.  To generate the nonce, implementations of
   this document MUST conform to TLSv1.3 (See [RFC8446], Section 5.3).

   The input and output lengths are as follows:

Yang                     Expires January 5, 2021                [Page 8]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

      the SM4 key length is 16 octets,

      the max plaintext length is 2^36 - 31 octets,

      the max AAD length is 2^61 - 1 octets,

      the nonce length is 12 octets,

      the authentication tag length is 16 octets, and

      the max ciphertext length is 2^36 - 15 octets.

   A security analysis of GCM is available in [MV04].

3.5.2.  AEAD_SM4_CCM

   The AEAD_SM4_CCM authenticated encryption algorithm works as
   specified in [CCM], using SM4 as the block cipher.  AEAD_SM4_CCM has
   four inputs: an SM4 key, a nonce, a plaintext, and optional
   additional authenticated data (AAD).  AEAD_SM4_CCM generates two
   outputs: a ciphertext and a message authentication code (also called
   an authentication tag).  The formatting and counter generation
   functions are as specified in Appendix A of [CCM], and the values of
   the parameters identified in that appendix are as follows:

      the nonce length n is 12,

      the tag length t is 16, and

      the value of q is 3.

   An authentication tag is also used in AEAD_SM4_CCM.  The generation
   of the authentication tag MUST conform to TLSv1.3 (See [RFC8446],
   Section 5.2).  The AEAD_SM4_CCM ciphertext is formed by appending the
   authentication tag provided as an output to the CCM encryption
   operation to the ciphertext that is output by that operation.  The
   input and output lengths are as follows:

      the SM4 key length is 16 octets,

      the max plaintext length is 2^24 - 1 octets,

      the max AAD length is 2^64 - 1 octets, and

      the max ciphertext length is 2^24 + 15 octets.

   To generate the nonce, implementations of this document MUST conform
   to TLSv1.3 (See [RFC8446], Section 5.3).

Yang                     Expires January 5, 2021                [Page 9]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

   A security analysis of CCM is available in [J02].

3.6.  Hash

   SM3 is defined by ISO in [ISO-SM3].  During a TLSv1.3 handshake with
   SM cipher suites, the hash function is REQUIRED to be SM3.
   Implementations MUST use SM3 for digest, key derivation, Transcript-
   Hash and other purposes during a TLSv1.3 key exchange process.

4.  IANA Considerations

   IANA has assigned the values {0x00, 0xC6} and {0x00, 0xC7} with the
   names TLS_SM4_GCM_SM3, TLS_SM4_CCM_SM3, to the "TLS Cipher Suite"
   registry with this document as reference:

    +-----------+-----------------+---------+-------------+-----------+
    |     Value | Description     | DTLS-OK | Recommended | Reference |
    +-----------+-----------------+---------+-------------+-----------+
    | 0x00,0xC6 | TLS_SM4_GCM_SM3 | No      | No          | this RFC  |
    |           |                 |         |             |           |
    | 0x00,0xC7 | TLS_SM4_CCM_SM3 | No      | No          | this RFC  |
    +-----------+-----------------+---------+-------------+-----------+

   IANA has assigned the value 0x0708 with the name 'sm2sig_sm3', to the
   "TLS SignatureScheme" registry:

            +--------+-------------+-------------+-----------+
            |  Value | Description | Recommended | Reference |
            +--------+-------------+-------------+-----------+
            | 0x0708 | sm2sig_sm3  | No          | this RFC  |
            +--------+-------------+-------------+-----------+

   IANA has assigned the value 41 with the name 'curveSM2', to the "TLS
   Supported Groups" registry:

        +-------+-------------+---------+-------------+-----------+
        | Value | Description | DTLS-OK | Recommended | Reference |
        +-------+-------------+---------+-------------+-----------+
        |    41 | curveSM2    | No      | No          | this RFC  |
        +-------+-------------+---------+-------------+-----------+

5.  Security Considerations

   At the time of writing, there are no known weak keys for SM
   cryptographic algorithms: SM2, SM3 and SM4, and no security issues
   have been found for these algorithms.

Yang                     Expires January 5, 2021               [Page 10]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

6.  References

6.1.  Normative References

   [CCM]      Dworkin, M, ., "NIST Special Publication 800-38C: The CCM
              Mode for Authentication and Confidentiality", May 2004,
              <http://csrc.nist.gov/publications/nistpubs/800-38C/
              SP800-38C.pdf>.

   [GCM]      Dworkin, M, ., "NIST Special Publication 800-38D:
              Recommendation for Block Cipher Modes of Operation:
              Galois/Counter Mode (GCM) and GMAC.", November 2007,
              <http://csrc.nist.gov/publications/nistpubs/800-38D/
              SP-800-38D.pdf>.

   [ISO-SM2]  International Organization for Standardization, "IT
              Security techniques -- Digital signatures with appendix --
              Part 3: Discrete logarithm based mechanisms", ISO ISO/IEC
              14888-3:2018, November 2018,
              <https://www.iso.org/standard/76382.html>.

   [ISO-SM3]  International Organization for Standardization, "IT
              Security techniques -- Hash-functions -- Part 3: Dedicated
              hash-functions", ISO ISO/IEC 10118-3:2018, October 2018,
              <https://www.iso.org/standard/67116.html>.

   [ISO-SM4]  International Organization for Standardization, "IT
              Security techniques -- Encryption algorithms -- Part 3:
              Block ciphers", ISO ISO/IEC 18038-3:2010, December 2010,
              <https://www.iso.org/standard/54531.html>.

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

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

Yang                     Expires January 5, 2021               [Page 11]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

6.2.  Informative References

   [GBT.32905-2016]
              Standardization Administration of China, "Information
              security technology --- SM3 cryptographic hash algorithm",
              GB/T 32905-2016, March 2017, <http://www.gmbz.org.cn/
              upload/2018-07-24/1532401392982079739.pdf>.

   [GBT.32907-2016]
              Standardization Administration of China, "Information
              security technology --- SM4 block cipher algorithm", GB/
              T 32907-2016, March 2017, <http://www.gmbz.org.cn/
              upload/2018-04-04/1522788048733065051.pdf>.

   [GBT.32918.2-2016]
              Standardization Administration of China, "Information
              security technology --- Public key cryptographic algorithm
              SM2 based on elliptic curves --- Part 2: Digital signature
              algorithm", GB/T 32918.2-2016, March 2017,
              <http://www.gmbz.org.cn/
              upload/2018-07-24/1532401673138056311.pdf>.

   [GBT.32918.5-2016]
              Standardization Administration of China, "Information
              security technology --- Public key cryptographic algorithm
              SM2 based on elliptic curves --- Part 5: Parameter
              definition", GB/T 32918.5-2016, March 2017,
              <http://www.gmbz.org.cn/
              upload/2018-07-24/1532401863206085511.pdf>.

   [GMT.0009-2012]
              State Cryptography Administration of China, "SM2
              cryptography algorithm application specification", GM/
              T 0009-2016, November 2012, <http://www.gmbz.org.cn/main/
              viewfile/2018011001400692565.html>.

   [J02]      Jonsson, J, ., "On the Security of CTR + CBC-MAC", 2002, <
              http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/propo
              sedmodes/ccm/ccm-ad1.pdf>.

   [MV04]     Viega, McGrew,., "The Security and Performance of the
              Galois/Counter Mode (GCM)", December 2004,
              <http://eprint.iacr.org/2004/193>.

Yang                     Expires January 5, 2021               [Page 12]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

Appendix A.  Test Vectors

   All values are in hexadecimal and are in network byte order (big
   endian).

A.1.  SM4-GCM Test Vectors

   Initialization Vector:   00001234567800000000ABCD
   Key:                     0123456789ABCDEFFEDCBA9876543210
   Plaintext:               AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB
                            CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD
                            EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF
                            EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA
   Associated Data:         FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2
   CipherText:              17F399F08C67D5EE19D0DC9969C4BB7D
                            5FD46FD3756489069157B282BB200735
                            D82710CA5C22F0CCFA7CBF93D496AC15
                            A56834CBCF98C397B4024A2691233B8D
   Authentication Tag:      83DE3541E4C2B58177E065A9BF7B62EC

A.2.  SM4-CCM Test Vectors

   Initialization Vector:   00001234567800000000ABCD
   Key:                     0123456789ABCDEFFEDCBA9876543210
   Plaintext:               AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB
                            CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD
                            EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF
                            EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA
   Associated Data:         FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2
   CipherText:              48AF93501FA62ADBCD414CCE6034D895
                            DDA1BF8F132F042098661572E7483094
                            FD12E518CE062C98ACEE28D95DF4416B
                            ED31A2F04476C18BB40C84A74B97DC5B
   Authentication Tag:      16842D4FA186F56AB33256971FA110F4

Appendix B.  Contributors

   Wuqiong Pan
   Ant Technology
   wuqiong.pwq@antfin.com

   Qin Long
   Ant Technology
   zhuolong.lq@antfin.com

   Kepeng Li
   Ant Technology
   kepeng.lkp@antfin.com

Yang                     Expires January 5, 2021               [Page 13]
Internet-Draft          TLSv1.3 SM Cipher Suites               July 2020

   Ke Zeng
   Ant Technology
   william.zk@antfin.com

   Han Xiao
   Ant Technology
   han.xiao@antfin.com

   Zhi Guan
   Peking University
   guan@pku.edu.cn

Author's Address

   Paul Yang
   Ant Technology
   No. 77 Xueyuan Road
   Hangzhou  310000
   China

   Phone: +86-571-2688-8888
   Fax:   +86-571-8643-2811
   Email: kaishen.yy@antfin.com

Yang                     Expires January 5, 2021               [Page 14]