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