ShangMi (SM) Cipher Suites for TLS 1.3
draft-yang-tls-tls13-sm-suites-06

draft-yang-tls-tls13-sm-suites has been presented for publication as an
Informational RFC on the Independent Stream.

This document describes how to apply a set of cipher suites in TLS 1.3
in support of the ShangMi (SM) cryptographic algorithms. The algorithm,
block cipher, and hash function that form part of these suites are
included in ISO documents referenced from this document.

The SM cipher suites "are becoming mandatory in China," and this
document serves to provide a description of how to use the SM cipher
suites with TLSv1.3 so that implementers can produce interworking
implementations.

The consumers of this document are likely to mainly be companies/
developers in China. Somewhat surpisingly, the Chinese Internet industry
(as opposed to the network operators and equipment manufacturers) pay as
much attention to RFCs as they do to national standards. While the SM
algorithms have been defined by the Chinese SCA and CSTC they haven't
done any work applicable to the area covered by this document.

The document makes it clear (Abstract and Introduction) that these
cipher suites are are not recommended by the IETF.  It also makes clear
(header, boilerplate, Section 1.2) that it is not a Standards Track
publication.

The necessary codepoints have already been allocated by IANA with
appropriate DE review and showing that the algorithms are not
recommended by the IETF. This allocation was done before the document
was even brought to the ISE. That means that publication of this
document is not required in order to assign the code points. However,
publication is deemed beneficial because this shows how the algorithms
are used.

This document was reviewed for the ISE by Tim Hudson, Paul Dale and
Rich Salz.

In preparation for RFC 5742 review on the -05 revision, Ben Kaduk read the document and made a number of suggestions for change (submitting them via GitHub). These changes were accepted and are found in the -06 revision.

== Tim Hudson ==

*- Would publication be a good/bad idea?*

A good idea - we need to standardise this usage and encourage migration
from earlier schemes.

This is part of what the TLS-1.3 would should be encouraging and
publication will move a user community forward into the current release.

*- Does it sit correctly in the cannon of TLS1.3 RFCs?*

Yes it does fit well within the cannon; although there do seem to be a
range of views that are against nationally defined algorithms expressed at
times - and getting this in place is a sensible move IMHO.

*- Is it clear enough to be published?  *
Yes it is clear.
There is always room for improvement in any IETF draft document - but
nothing stood out to me as needing adjustment from a technical clarity
perspective.

== Paul Dale ==

> Would publication be a good/bad idea?

I think it would be worthwhile.


> Does it sit correctly in the cannon of TLS1.3 RFCs?

I believe so.


> Is it clear enough to be published?

For the most part yes, but:

1. there are some clumsily worded parts;
2. there are a couple of places that could do with some introductory words and
3. one phrase was insufficiently clear for me to determine the intent:
          "which in details MUST be constructed by the TLS record header".

I've attached a LibreOffice document which includes a number of wording changes and
a few comments.  Treat all as suggestions only. 


== Rich Salz ==

As a minor point, I kept being "surprised" (although that is too strong a word) so
see things in the order "SM2 SM4 SM3"

The document is clear and understandable.  This is notable because English is not
their native language; good job.

It might make sense to worthwhile to put the "becoming mandatory in China" earlier
up in the document.

Having test vectors is great.

== ISE First review ==

Title

Can you please expand "SM"

---

Abstract

Can you please expand "SM"

---

Abstract

Please add a second paragraph to help understand the purpose, intent,
and status of the work. Something like...

  The use of these cipher suites with TLS 1.3 is not endorsed or
  recommended by the IETF.  This document provides a description of
  how to use the SM cypher suites with TLS 1.3 so that implementers
  may produce interworking implementations.

We can negotiate these words if you like, in particular to strengthen
the reason why this document is published.

---

Global change s/draft/document/ except in the boilerplate text.

---

Can you add a similar additional paragraph (as added to the Abstract) to
the end of section 1 (before section 1.1).

---

Section 1

OLD
  This document describes two new cipher suites for the Transport Layer
  Security (TLS) protocol version 1.3 (a.k.a TLSv1.3, [RFC8446]).  The
  new cipher suites are listed as follows (or Section 2):
NEW
  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):
END

---

Section 1

s/cipher suites contains/cipher suites contain/

s/For the more/For a more/

s/meet the need of/meet the needs of/

s/encryption key and protect/encryption keys and protect/

---

Please expand abbreviations on first use. I see:

AEAD
CCM
ECDHE
GCM
SM
SM2
SM3
SM4

---

1.2

Please use the new boilerplate text and add your modifications as
follows:

  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.

You will need to add a reference for RFC 8174.

---

Section 2. Title

OLD
2.  Proposed Cipher Suites
NEW
2.  Supported Cipher Suites
END

---

3.1

OLD
  The only capable version for the new cipher suites defined in this
  document is TLSv1.3.  Implementations of this document MUST NOT apply
  these cipher suites into any TLS protocols that have an older version
  than 1.3.
NEW
  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.
END

---

3.2.1

s/use SM2 signature/use the SM2 signature/

s/SM2 signature is defined/The SM2 signature is defined/

---

3.2.1

  In general, SM2 is a
  signature algorithm based on elliptic curves.

Why "in general"?

Maybe just write...

  SM2 is a
  signature algorithm based on elliptic curves.

---

3.2.1

OLD
  This curve has the name curveSM2 and IANA is
  requested to assign a value for it.
NEW
  This curve is named curveSM2 and has been assigned the value 41 as
  shown in Section 4.
END

---

3.2.1

OLD
  Unlike other elliptic curve
  based public key algorithm like ECDSA, SM2 cannot select other
  elliptic curves in practice, but it's allowed to write test cases by
  using other elliptic curve parameter sets for SM2, take Annex F.14 of
  [ISO-SM2] as a reference.
NEW
  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.
END

---

3.2.1

s/SM2 signature algorithm requests/The SM2 signature algorithm requests/

s/when generate/when generating/

---

3.3.1.1.

s/is REQUIRED to include/MUST include/

---

3.3.1.2

  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.

This is all fine, but since you have "MAY" can you also please include
some text to explain:
- how the server might choose to use or not use the cipher suites
- what would happen if it chose to not use the cipher suites

---

3.3.2

s/authentication purpose/authentication purposes/

---

3.3.3

s/When server sends/When a server sends/

---

3.3.4

OLD
signature algorithm MUST be SM2 signature algorithm.
NEW
signature algorithm MUST be SM2.
END

---

3.4

  Implementations of this
  document SHOULD always conform to what TLSv1.3 [RFC8446] and its
  successors require about the key derivation and related methods.

This use of "SHOULD" worries me!
I would prefer that you use "MUST", but if you really want "SHOULD" you
need to explain how/why an implementation might vary from the IETF
standards track documents.

---

3.5.1

s/and plaintext/plaintext/

s/authentication tag conformed/authentication tag conforming/

---

3.5.1

  which in details SHOULD be
  constructed by the TLS record header.

Again, I am worried by "SHOULD".
Either change to "MUST" or supply some description of the variance.

---

3.5.2

s/An authentication tag conformed/An authentication tag conforming/

---

There is an error in the IANA section:

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

There is no "DTLS-OK" column in this registry.

---

5.

s/_MUST NOT_/MUST NOT/

---

You can delete Appendix B, I think.


== ISE Final Review ==


Section 1.2

Please make this section read...

  Although this document is not an IETF Standards Track publication it
  adopts the conventions for normatve language to provide clarity of
  instructions to the implementer, and to indicate requirement levels
  for compliant TLSv1.3 implementations.

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

---

Section 2

It would be good if you could use bullets such as:

  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:

  o 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 };

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

        NamedGroup curveSM2 = { 41 };

---

3.1

s/cpher/cipher/

---

3.2.1

s/[ISO-SM2].  SM2/[ISO-SM2].  The SM2/
s/curves.  SM2/curves.  The SM2/

---

3.2.1 has

  Implementations of the cipher suites defined in this document SHOULD
  conform to what [GBT.32918.5-2016] requires

Usually, when we see a SHOULD, we expect to see an alternative and a
reason. In this case, why would an implementation not conform to the
reference, and to what would it actually conform?

(There's a couple of good examples of doing this right in 3.3.1.2.)

---

3.2.1

Some similar issues with MUST and SHOULD. You have...

  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]:

1. You have a MUST that is varied by an "Except if". That can be
  confusing, although it is possible to parse it correctly. Maybe this
  could be "In all uses except when a client of server needs to verify
  a peer's SM2 certificate in the Certificate message, an
  implementation of this document MUST..." And then, for the second
  paragraph, "If either a client or...."

2. You have a SHOULD that I think is probably meant to be a MUST. That
  is, I think that in all cases where an SM2 certificate is being
  verified, the SM2 identifier MUST be used.

---

3.3.2

s/if server chooses/if the server chooses/


---

3.3.2

      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.

Another "SHOULD"

---

3.4

OLD
  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.
NEW
  This document does not define an SM2 key exchange protocol, and SM2
  SHALL NOT be used in the key exchange steps defined in Section 3.3.
END

---

3.5.1

s/constructed by the details/constructed using the details/

---

3.5.1

  The nonce is generated by the party performing the authenticated
  encryption operation.
  Within the scope of any authenticated-encryption key, the nonce value

Possible missing paragraph break.

---

3.5.1

s/TLSv1.3 (See/TLSv1.3 (see/

---

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.

Should this list also have...

      the SM4 key length is 16 octets,

---

Section 5

Please point again to the various security analysis work.

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

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

draft-yang-tls-tls13-sm-suites has been presented for publication as an
Informational RFC on the Independent Stream.

This document describes how to apply a set of cipher suites in TLS 1.3
in support of the ShangMi (SM) cryptographic algorithms. The algorithm,
block cipher, and hash function that form part of these suites are
included in ISO documents referenced from this document.

The SM cipher suites "are becoming mandatory in China," and this
document serves to provide a description of how to use the SM cipher
suites with TLSv1.3 so that implementers can produce interworking
implementations.

The consumers of this document are likely to mainly be companies/
developers in China. Somewhat surpisingly, the Chinese Internet industry
(as opposed to the network operators and equipment manufacturers) pay as
much attention to RFCs as they do to national standards. While the SM
algorithms have been defined by the Chinese SCA and CSTC they haven't
done any work applicable to the area covered by this document.

The document makes it clear (Abstract and Introduction) that these
cipher suites are are not recommended by the IETF.  It also makes clear
(header, boilerplate, Section 1.2) that it is not a Standards Track
publication.

The necessary codepoints have already been allocated by IANA with
appropriate DE review and showing that the algorithms are not
recommended by the IETF. This allocation was done before the document
was even brought to the ISE. That means that publication of this
document is not required in order to assign the code points. However,
publication is deemed beneficial because this shows how the algorithms
are used.

This document was reviewed for the ISE by Tim Hudson, Paul Dale and
Rich Salz.



== Tim Hudson ==

*- Would publication be a good/bad idea?*

A good idea - we need to standardise this usage and encourage migration
from earlier schemes.
This is part of what the TLS-1.3 would should be encouraging and
publication will move a user community forward into the current release.

*- Does it sit correctly in the cannon of TLS1.3 RFCs?*

Yes it does fit well within the cannon; although there do seem to be a
range of views that are against nationally defined algorithms expressed at
times - and getting this in place is a sensible move IMHO.

*- Is it clear enough to be published?  *
Yes it is clear.
There is always room for improvement in any IETF draft document - but
nothing stood out to me as needing adjustment from a technical clarity
perspective.

== Paul Dale ==

> Would publication be a good/bad idea?

I think it would be worthwhile.


> Does it sit correctly in the cannon of TLS1.3 RFCs?

I believe so.


> Is it clear enough to be published?

For the most part yes, but:

1. there are some clumsily worded parts;
2. there are a couple of places that could do with some introductory words and
3. one phrase was insufficiently clear for me to determine the intent:
          "which in details MUST be constructed by the TLS record header".

I've attached a LibreOffice document which includes a number of wording changes and
a few comments.  Treat all as suggestions only. 


== Rich Salz ==

As a minor point, I kept being "surprised" (although that is too strong a word) so
see things in the order "SM2 SM4 SM3"

The document is clear and understandable.  This is notable because English is not
their native language; good job.

It might make sense to worthwhile to put the "becoming mandatory in China" earlier
up in the document.

Having test vectors is great.

== ISE First review ==

Title

Can you please expand "SM"

---

Abstract

Can you please expand "SM"

---

Abstract

Please add a second paragraph to help understand the purpose, intent,
and status of the work. Something like...

  The use of these cipher suites with TLS 1.3 is not endorsed or
  recommended by the IETF.  This document provides a description of
  how to use the SM cypher suites with TLS 1.3 so that implementers
  may produce interworking implementations.

We can negotiate these words if you like, in particular to strengthen
the reason why this document is published.

---

Global change s/draft/document/ except in the boilerplate text.

---

Can you add a similar additional paragraph (as added to the Abstract) to
the end of section 1 (before section 1.1).

---

Section 1

OLD
  This document describes two new cipher suites for the Transport Layer
  Security (TLS) protocol version 1.3 (a.k.a TLSv1.3, [RFC8446]).  The
  new cipher suites are listed as follows (or Section 2):
NEW
  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):
END

---

Section 1

s/cipher suites contains/cipher suites contain/

s/For the more/For a more/

s/meet the need of/meet the needs of/

s/encryption key and protect/encryption keys and protect/

---

Please expand abbreviations on first use. I see:

AEAD
CCM
ECDHE
GCM
SM
SM2
SM3
SM4

---

1.2

Please use the new boilerplate text and add your modifications as
follows:

  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.

You will need to add a reference for RFC 8174.

---

Section 2. Title

OLD
2.  Proposed Cipher Suites
NEW
2.  Supported Cipher Suites
END

---

3.1

OLD
  The only capable version for the new cipher suites defined in this
  document is TLSv1.3.  Implementations of this document MUST NOT apply
  these cipher suites into any TLS protocols that have an older version
  than 1.3.
NEW
  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.
END

---

3.2.1

s/use SM2 signature/use the SM2 signature/

s/SM2 signature is defined/The SM2 signature is defined/

---

3.2.1

  In general, SM2 is a
  signature algorithm based on elliptic curves.

Why "in general"?

Maybe just write...

  SM2 is a
  signature algorithm based on elliptic curves.

---

3.2.1

OLD
  This curve has the name curveSM2 and IANA is
  requested to assign a value for it.
NEW
  This curve is named curveSM2 and has been assigned the value 41 as
  shown in Section 4.
END

---

3.2.1

OLD
  Unlike other elliptic curve
  based public key algorithm like ECDSA, SM2 cannot select other
  elliptic curves in practice, but it's allowed to write test cases by
  using other elliptic curve parameter sets for SM2, take Annex F.14 of
  [ISO-SM2] as a reference.
NEW
  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.
END

---

3.2.1

s/SM2 signature algorithm requests/The SM2 signature algorithm requests/

s/when generate/when generating/

---

3.3.1.1.

s/is REQUIRED to include/MUST include/

---

3.3.1.2

  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.

This is all fine, but since you have "MAY" can you also please include
some text to explain:
- how the server might choose to use or not use the cipher suites
- what would happen if it chose to not use the cipher suites

---

3.3.2

s/authentication purpose/authentication purposes/

---

3.3.3

s/When server sends/When a server sends/

---

3.3.4

OLD
signature algorithm MUST be SM2 signature algorithm.
NEW
signature algorithm MUST be SM2.
END

---

3.4

  Implementations of this
  document SHOULD always conform to what TLSv1.3 [RFC8446] and its
  successors require about the key derivation and related methods.

This use of "SHOULD" worries me!
I would prefer that you use "MUST", but if you really want "SHOULD" you
need to explain how/why an implementation might vary from the IETF
standards track documents.

---

3.5.1

s/and plaintext/plaintext/

s/authentication tag conformed/authentication tag conforming/

---

3.5.1

  which in details SHOULD be
  constructed by the TLS record header.

Again, I am worried by "SHOULD".
Either change to "MUST" or supply some description of the variance.

---

3.5.2

s/An authentication tag conformed/An authentication tag conforming/

---

There is an error in the IANA section:

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

There is no "DTLS-OK" column in this registry.

---

5.

s/_MUST NOT_/MUST NOT/

---

You can delete Appendix B, I think.


== ISE Final Review ==


Section 1.2

Please make this section read...

  Although this document is not an IETF Standards Track publication it
  adopts the conventions for normatve language to provide clarity of
  instructions to the implementer, and to indicate requirement levels
  for compliant TLSv1.3 implementations.

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

---

Section 2

It would be good if you could use bullets such as:

  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:

  o 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 };

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

        NamedGroup curveSM2 = { 41 };

---

3.1

s/cpher/cipher/

---

3.2.1

s/[ISO-SM2].  SM2/[ISO-SM2].  The SM2/
s/curves.  SM2/curves.  The SM2/

---

3.2.1 has

  Implementations of the cipher suites defined in this document SHOULD
  conform to what [GBT.32918.5-2016] requires

Usually, when we see a SHOULD, we expect to see an alternative and a
reason. In this case, why would an implementation not conform to the
reference, and to what would it actually conform?

(There's a couple of good examples of doing this right in 3.3.1.2.)

---

3.2.1

Some similar issues with MUST and SHOULD. You have...

  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]:

1. You have a MUST that is varied by an "Except if". That can be
  confusing, although it is possible to parse it correctly. Maybe this
  could be "In all uses except when a client of server needs to verify
  a peer's SM2 certificate in the Certificate message, an
  implementation of this document MUST..." And then, for the second
  paragraph, "If either a client or...."

2. You have a SHOULD that I think is probably meant to be a MUST. That
  is, I think that in all cases where an SM2 certificate is being
  verified, the SM2 identifier MUST be used.

---

3.3.2

s/if server chooses/if the server chooses/


---

3.3.2

      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.

Another "SHOULD"

---

3.4

OLD
  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.
NEW
  This document does not define an SM2 key exchange protocol, and SM2
  SHALL NOT be used in the key exchange steps defined in Section 3.3.
END

---

3.5.1

s/constructed by the details/constructed using the details/

---

3.5.1

  The nonce is generated by the party performing the authenticated
  encryption operation.
  Within the scope of any authenticated-encryption key, the nonce value

Possible missing paragraph break.

---

3.5.1

s/TLSv1.3 (See/TLSv1.3 (see/

---

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.

Should this list also have...

      the SM4 key length is 16 octets,

---

Section 5

Please point again to the various security analysis work.

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

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