TLS P. Yang Internet-Draft Ant Financial Intended status: Informational November 26, 2019 Expires: May 29, 2020 ShangMi (SM) Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3 draft-yang-tls-tls13-sm-suites-02 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 May 29, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Yang Expires May 29, 2020 [Page 1] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 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 as follows (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 May 29, 2020 [Page 2] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 a more detailed introduction to SM cryptographic algorithms, please read Section 1.1. These cipher suites follow what TLSv1.3 requires. For instance, 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 now 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 May 29, 2020 [Page 3] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 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, more 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 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 algorithm 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. Implementations of the cipher suites defined in this document SHOULD conform to what [GBT.32918.5-2016] requires, that is to say, the only Yang Expires May 29, 2020 [Page 4] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 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 the signature, as well as when verifying an SM2 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, the following ASCII string value SHOULD be used as the SM2 identifier according to [GMT.0009-2012]: 1234567812345678 In the octet presentation, it should be: 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 other values rather than the one mentioned above. Implementations of this document SHOULD confirm this information by themselves. Yang Expires May 29, 2020 [Page 5] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 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 supported_groups extension, 'curveSM2' MUST be included; o For signature_algorithms extension, 'sm2sig_sm3' MUST be included; o For signature_algorithms_cert extension (if presented), 'sm2sig_sm3' MUST be included; o For 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 sends 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 a TLSv1.3 client provides; otherwise the server MUST abort the handshake with a "illegal_parameter" alert. The following extensions MUST conform to the new requirements: Yang Expires May 29, 2020 [Page 6] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 o For 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 finally chooses to use a 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 which contains 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 for 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 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 May 29, 2020 [Page 7] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 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 of what [RFC5116] has 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 what Section 5.2 of TLSv1.3 [RFC8446] requires is used, which in details MUST be constructed by 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 duplicate values. Using the same nonce for two different messages encrypted with the same key destroys the security properties.To generate the nonce, implementations of this document MUST conform to what TLSv1.3 specifies (See [RFC8446], Section 5.3). AAD is authenticated but not encrypted. Thus, the AAD is not included in the SM4-CCM output. It can be used to authenticate plaintext packet headers. The input and output lengths are as follows: Yang Expires May 29, 2020 [Page 8] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 SM4 key length is 16 octets, Max plaintext length is 2^36 - 31 octets, Max AAD length is 2^61 - 1 octets, Nonce length is 12 octets, Authentication tag length is 16 octets, and 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 function are as specified in Appendix A of that reference, 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 conforming to what Section 5.2 of TLSv1.3 [RFC8446] requires is used, which in details MUST be constructed by the TLS record header. 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: SM4 key length is is 16 octets, Max plaintext length is 2^24 - 1 octets, Max AAD length is 2^64 - 1 octets, and Max Ciphertext length is 2^24 + 15 octets. To generate the nonce, implementations of this document MUST conform to what TLSv1.3 specifies (See [RFC8446], Section 5.3). Yang Expires May 29, 2020 [Page 9] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 A security analysis of CCM is available in [J02]. 3.6. Hash SM3 is defined by ISO as [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, as shown below. +-----------+-----------------+---------+-------------+-----------+ | 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, as shown below. +--------+-------------+-------------+-----------+ | 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, as shown below. +-------+-------------+---------+-------------+-----------+ | Value | Description | DTLS-OK | Recommended | Reference | +-------+-------------+---------+-------------+-----------+ | 41 | curveSM2 | No | No | this RFC | +-------+-------------+---------+-------------+-----------+ 5. Security Considerations At the time of writing this document, there are no known weak keys for SM cryptographic algorithms SM2, SM3 and SM4, and no security problem has been found on those algorithms. Yang Expires May 29, 2020 [Page 10] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 o The cipher suites described in this document MUST NOT be used with TLSv1.2 or earlier. 6. References 6.1. Normative References [CCM] Dworkin, M, ., "NIST Special Publication 800-38C: The CCM Mode for Authentication and Confidentiality", May 2004, . [GCM] Dworkin, M, ., "NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.", November 2007, . [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, . [ISO-SM3] International Organization for Standardization, "IT Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions", ISO ISO/IEC 10118-3:2018, October 2018, . [ISO-SM4] International Organization for Standardization, "IT Security techniques -- Encryption algorithms -- Part 3: Block ciphers", ISO ISO/IEC 18038-3:2010, December 2010, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Yang Expires May 29, 2020 [Page 11] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 6.2. Informative References [GBT.32905-2016] Standardization Administration of China, "Information security technology --- SM3 cryptographic hash algorithm", GB/T 32905-2016, March 2017, . [GBT.32907-2016] Standardization Administration of China, "Information security technology --- SM4 block cipher algorithm", GB/ T 32907-2016, March 2017, . [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, . [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, . [GMT.0009-2012] State Cryptography Administration of China, "SM2 cryptography algorithm application specification", GM/ T 0009-2016, November 2012, . [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, . Yang Expires May 29, 2020 [Page 12] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 Appendix A. Test Vectors All values are in hexadecimal and are in network 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 Financial wuqiong.pwq@antfin.com Qin Long Ant Financial zhuolong.lq@antfin.com Kepeng Li Ant Financial kepeng.lkp@antfin.com Yang Expires May 29, 2020 [Page 13] Internet-Draft TLSv1.3 SM Cipher Suites November 2019 Ke Zeng Ant Financial william.zk@antfin.com Han Xiao Ant Financial han.xiao@antfin.com Author's Address Paul Yang Ant Financial No. 77 Xueyuan Road Hangzhou 310000 China Phone: +86-571-2688-8888 Fax: +86-571-8643-2811 Email: kaishen.yy@antfin.com Yang Expires May 29, 2020 [Page 14]