Last Call Review of draft-ietf-lamps-cms-shakes-11
review-ietf-lamps-cms-shakes-11-secdir-lc-migault-2019-07-01-00

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.

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

</mglt>

   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.

<mglt>
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.
</mglt>

   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.

<mglt>
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
</mglt>

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

<mglt>
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.
</mglt>

   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.

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

</mglt>

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.

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

</mglt>

   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.

<mglt>
I suggest we use bytes or bits in the document.
</mglt>

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.

<mglt>
same comment regarding the parameter field
</mglt>

4.3.  Public Keys

   The identifier parameters, as explained in Section 3, MUST be absent.
<mglt>
Same comment as above.
</mglt>
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.

<mglt>
I would suggest to add some considerations on resistance with post
quantum computers.
</mglt>