Hi
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
I believe the document is ready with nits.
Yours,
Daniel
LAMPS WG P. Kampanakis
Internet-Draft Cisco Systems
Updates: 3370 (if approved) Q. Dang
Intended status: Standards Track NIST
Expires: December 19, 2019 June 17, 2019
Use of the SHAKE One-way Hash Functions in the Cryptographic Message
Syntax (CMS)
draft-ietf-lamps-cms-shakes-11
2. Introduction
In the SHA-3 family, two extendable-output functions (SHAKEs),
SHAKE128 and SHAKE256, are defined. Four other hash function
instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also
defined but are out of scope for this document. A SHAKE is a
variable length hash function defined as SHAKE(M, d) where the output
is a d-bits long digest of message M. The corresponding collision
and second preimage resistance strengths for SHAKE128 are
min(d/2,128) and min(d,128) bits respectively (Appendix A.1 [SHA3]).
And, the corresponding collision and second preimage resistance
strengths for SHAKE256 are min(d/2,256) and min(d,256) bits
respectively.
since we are introducing d in this section and the specification fixes d
later, we may fix d here and list the associated security for the fixed
value.
I would also suggest that additional resistance considerations be
mentioned in the security consideration with a reference to it in the
introduction. Additional consideration would also provide preimage
resistance and extends the considerations regarding 128/256 bit security
and post quantum resistance.
A SHAKE can be used in CMS as the message digest function (to hash
the message to be signed) in RSASSA-PSS and ECDSA, message
authentication code and as the mask generation function (MGF) in
RSASSA-PSS. This specification describes the identifiers for SHAKEs
to be used in CMS and their meaning.
3. Identifiers
This section defines four new object identifiers (OIDs) for using
SHAKE128 and SHAKE256 in CMS.
It is unclear to me if this section defines OIDs. Instead, it seems to
me that the section lists OIDs for convenience but these are defined in
other documents.
Two object identifiers for SHAKE128 and SHAKE256 hash functions are
defined in [shake-nist-oids] and we include them here for
convenience.
id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 2 11 }
id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 2 12 }
In this specification, when using the id-shake128 or id-shake256
algorithm identifiers, the parameters MUST be absent. That is, the
identifier SHALL be a SEQUENCE of one component, the OID.
It might be clearer if the AlgoritmIdentifier structure is added
for convenience or referenced maybe by RFC5280 in the document.
On the other hand, I am also inclined to think that this section may be
replaced with a reference to lamps-pkix-shake.and the list of id-*.
This could be one sentence in the introduction
4. Use in CMS
4.1. Message Digests
The id-shake128 and id-shake256 OIDs (Section 3) can be used as the
digest algorithm identifiers located in the SignedData, SignerInfo,
DigestedData, and the AuthenticatedData digestAlgorithm fields in CMS
x [RFC5652]. The encoding MUST omit the parameters field and the
I might be missing one level of encapsulation, but my understanding is
that digest algorithm identifiers and algorithm identifiers have the
same structure. If that is correct, it seems that the requirement to
omit the parameters is redundant with the definition of the algorithm
identifiers as well as with lamps-pkix-shake.
I am reading the sentence as it provides some requirements on the
message format (no parameters are provided) as well as the setting of an
output size. I interpret the output size as a parameter for the
message-digesting algorithm as opposed as a parameter that is provided
in the message. If that is the case, that might be specified explicitly
and maybe in two different sentences as to avoid coupling requirements
of different nature.
output size, d, for the SHAKE128 or SHAKE256 message digest MUST be
256 or 512 bits respectively.
The digest values are located in the DigestedData field and the
Message Digest authenticated attribute included in the
signedAttributes of the SignedData signerInfo. In addition, digest
values are input to signature algorithms. The digest algorithm MUST
be the same as the message hash algorithms used in signatures.
4.2. Signatures
In CMS, signature algorithm identifiers are located in the SignerInfo
signatureAlgorithm field of SignedData content type and
countersignature attribute. Signature values are located in the
SignerInfo signature field of SignedData content type and
countersignature attribute.
Conforming implementations that process RSASSA-PSS and ECDSA with
SHAKE signatures when processing CMS data MUST recognize the
corresponding OIDs specified in Section 3.
When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA
curve order SHOULD be chosen in line with the SHAKE output length.
In the context of this document SHAKE128 OIDs are RECOMMENDED for
2048 or 3072-bit RSA modulus or curves with group order of 256-bits.
SHAKE256 OIDs are RECOMMENDED for 4096-bit RSA modulus and higher or
curves with group order of 384-bits and higher.
I believe a reference to the security consideration should be provided
with further discussions on the meaning of "in line". The security
consideration should maybe provide a reference that correlates symmetric
- as CMS can be used with AES -, factoring modulus Elliptic curves and
hash. Though the current security consideration reference SP800-78-4 and
SP800-107, maybe the following ones could be used in the security
consideration. They look more recent but I have not deeply looked at
those.
* Algorithms, Key Size and Protocols Report (2018), H2020-ICT-2014 – Project 645421, D5.4, ECRYPT-CSA, 02/2018.
* Recommendation for Key Management, Special Publication 800-57 Part 1 Rev. 4, NIST, 01/2016.
4.2.1. RSASSA-PSS Signatures
The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA-
PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is
used, the encoding MUST omit the parameters field. That is, the
AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA-
PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA-
PSS-params that are used to define the algorithms and inputs to the
algorithm. This specification does not use parameters because the
hash, mask generation algorithm, trailer and salt are embedded in the
OID definition.
This is a similar comment as the one provided earlier. It does not seem
to me that this document "specifies" (in section 3) algorithms. It seems
to me these algorithms are provided for convenience but are specified in
pkix-shake.
Similarly, the absence of parameter does not seems to me necessary here
- unless I am missing something. It seems that MUST and SHALL are
aiming at preventing the NULL parameter, I am wondering if there are any
reasons for having different terms.
The explanation may be moved to section 3.
The hash algorithm to hash a message being signed and the hash
algorithm as the mask generation function used in RSASSA-PSS MUST be
the same, SHAKE128 or SHAKE256 respectively. The output-length of
the hash algorithm which hashes the message SHALL be 32 or 64 bytes
respectively.
I suggest we use bytes or bits in the document.
4.2.2. ECDSA Signatures
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
[X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256
(specified in Section 3) algorithm identifier appears, the respective
SHAKE function is used as the hash. The encoding MUST omit the
parameters field. That is, the AlgorithmIdentifier SHALL be a
SEQUENCE of one component, the OID id-ecdsa-with-shake128 or id-
ecdsa-with-shake256.
same comment regarding the parameter field
4.3. Public Keys
The identifier parameters, as explained in Section 3, MUST be absent.
Same comment as above.
4.4. Message Authentication Codes
6. Security Considerations
This document updates [RFC3370]. The security considerations section
of that document applies to this specification as well.
NIST has defined appropriate use of the hash functions in terms of
the algorithm strengths and expected time frames for secure use in
Special Publications (SPs) [SP800-78-4] and [SP800-107]. These
documents can be used as guides to choose appropriate key sizes for
various security scenarios.
When more than two parties share the same message-authentication key,
data origin authentication is not provided. Any party that knows the
message-authentication key can compute a valid MAC, therefore the
content could originate from any one of the parties.
I would suggest to add some considerations on resistance with post
quantum computers.