Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-hash-sig-09: (with DISCUSS and COMMENT)

[Russ Housley <[e-mail]>]

> On Sep 13, 2019, at 3:10 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lamps-cms-hash-sig-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Two fairly minor points that should be easy to resolve, but seem to be
> worth some time:
> 
> I think we need to be a bit more clear about what exactly the contents
> of the signature OCTET STRING are.  Section 3 has a fairly abstract note
> about including enough information to be self-describing (within the
> HSS/LMS variants), and Section 5 does better with "the single HSS
> signature value resulting from the signing operation as specified in
> [HASHSIG]", but it doesn't seem too burdensome to say something like
> "the string returned from Algorithm 3 in [RFC8554]" or even refer back
> to the description language at the end of Section 2 and avoid any
> confusion.

I suggest:

   The signature value is a large OCTET STRING as described in Section 2
   of this document.  The signature format is designed for easy parsing.
   The HSS, LMS, and LMOTS component of the signature value each format
   include a counter and a type code that indirectly providing all of
   the information that is needed to parse the value during signature
   validation.

> Section 5 has a "MUST" for using the same hash for the CMS
> digestAlgorithm and the HSS/LMS tree, but Section 6 only has a "SHOULD"
> for the message-digest attribute's digest and the signed attributes
> digest (the latter of which MUST be the HSS/LMS hash per the previous);
> should these two requirements be at the same level of normativity?  I'm
> not sure why the one would be more important for correct operation than
> the other.

The MUST comes from discussion on the mail list.  Please see:

   https://mailarchive.ietf.org/arch/msg/spasm/ZJnHLMAsi8229TWUiDZUMN0noFM <https://mailarchive.ietf.org/arch/msg/spasm/ZJnHLMAsi8229TWUiDZUMN0noFM>

As you can see from Scott's message, the design in RFC 8554 expects the same hash to be used in both places.

Currently, CMS does not require the same hash algorithm to be used to compute the message digest of the content and the signed attributes (if any are present).  RFC 6211 points out that it is normal practice for them to be the same.  I would argue that it is time for an update to RFC 5652 to REQUIRE them to be the same, but that should not fall to this document.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1
> 
>   based digital signature, and it is described in [HASHSIG].  The
>   HSS/LMS signature algorithm can only be used for a fixed number of
>   signing operations.  [...]
> 
> nit: with a given key

Yes.  ... with a given private key.
> 
>   use.  A post-quantum cryptosystem [PQC] is a system that is secure
>   against quantum computers that have more than a trivial number of
>   quantum bits (qu-bits).  It is open to conjecture when it will be
> 
> nit(?): I'm much more used to seeing "q-bits" or "qbits" than "qu-bits".

draft-hoffman-c2pq-05 uses "qubits".  I'll drop the hypen.

> Section 2.2
> 
> It's a bit unfortunate that we have to mix 0- (signed public keys) and
> 1-based (tree nodes) indexing, but it seems that this is inherent in RFC
> 8554 and not really avoidable in this document.

Yes. I need to be aligned with [HASHSIG].
 
> Section 3
> 
>   The signature value identifies the hash function used in the HSS/LMS
>   tree.  In [HASHSIG] only the SHA-256 hash function [SHS] is
>   supported, but it also establishes an IANA registry [IANA-LMS] to
>   permit the registration of additional hash functions in the future.
> 
> (This pattern occurs in several places, but I pick an arbitrary one to
> comment on) I am not sure that the "In [HASHSIG] only <foo> is
> supported, but it also establishes an IANA registry" is going to present
> the best interface to readers; the language in Section 2 about "the
> algorithm specified in [HASHSIG] currently only uses <foo>, but it also
> establishes an IANA registry to permit the registration of additional
> [...]" seems to give more emphasis on the registry as opposed to the
> snapshot in [HASHSIG].  On the other hand, someone is probably going to
> complain that "currently" will not age well...

I suggest:

  ...  The hash-based signature
   algorithm specified in [HASHSIG] uses only the SHA-256 one-way hash
   function [SHS], but it establishes an IANA registry [IANA-LMS] to
   permit the registration of additional one-way hash functions in the
   future.

> Section 4
> 
> It feels a little surprising to make explicit requirements on the
> keyUsage contents but not say anything about extendedKeyUsage.  Having a
> static whitelist of EKU OIDs is not reasonable, of course, and the
> PUBLIC-KEY class from RFC 5912 only covers regular keyUsage, but some
> advice about "encipherment methods are not going to make sense" might
> still be appropriate.

That is what the "it MUST NOT contain other values" does.  RFC 5280 define the keyUsage bits as:

      KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

>   The public key value is an OCTET STRING.  Like the signature format,
>   it is designed for easy parsing.  The value is the number of levels
>   in the public key, L, followed by the LMS public key.
> 
>   The HSS/LMS public key value can be summarized as:
> 
>      u32str(L) || lms_public_key
> 
> "Can be summarized as" does not say to me "here is a rigorous protocol
> specification" (though it does seem to actually be one, given the
> notation used in this document and 8554).  So unlike the signature OCTET
> STRING contents, this one is not DISCUSS-worthy, since it's in the same
> section as the thing being described.

It would be better to say:

   The HSS/LMS public key value can be described as:

> Section 5
> 
>   When signed attributes are absent, the HSS/LMS signature is computed
>   over the content.  When signed attributes are present, a hash is
>   computed over the content using the same hash function that is used
>   in the HSS/LMS tree, and then a message-digest attribute is
>   constructed to contain the resulting hash value, and then the result
>   of DER encoding the set of signed attributes (which MUST include a
>   content-type attribute and a message-digest attribute, and then the
>   HSS/LMS signature is computed over the DER-encoded output.  In
> 
> nit(?): is this "the message-digest attribute" constructed in the
> previous step (as opposed to any old message-digest attribute)?

I hope this is more clear:

   When signed attributes are absent, the HSS/LMS signature is computed
   over the content.  When signed attributes are present, a hash is
   computed over the content using the same hash function that is used
   in the HSS/LMS tree, and then a message-digest attribute is
   constructed with the hash of the content, and then the HSS/LMS
   signature is computed over the DER-encoded set of signed attributes
   (which MUST include a content-type attribute and a message-digest
   attribute).  In summary:

      IF (signed attributes are absent)
      THEN HSS_LMS_Sign(content)
      ELSE message-digest attribute = Hash(content);
           HSS_LMS_Sign(DER(SignedAttributes))

> Section 6
> 
>   tracking data can cause a one-time key to be used more than once.  As
>   a result, when a private key and the tracking data are stored on non-
>   volatile media or stored in a virtual machine environment, care must
>   be taken to preserve confidentiality and integrity.
> 
> It might be worth explicitly noting "in the face of failed writes,
> virtual machine snapshotting or cloning, and other operational
> concerns".

I suggest:

   Implementations MUST protect the private keys.  Compromise of the
   private keys may result in the ability to forge signatures.  Along
   with the private key, the implementation MUST keep track of which
   leaf nodes in the tree have been used.  Loss of integrity of this
   tracking data can cause a one-time key to be used more than once.  As
   a result, when a private key and the tracking data are stored on non-
   volatile media or stored in a virtual machine environment, failed
   writes, virtual machine snapshotting or cloning, and other
   operational concerns must be considered to ensure confidentiality and
   integrity.

> Appendix: ASN.1 Module
> 
>   MTS-HashSig-2013
> 
> Once written, the module name can never change? :)

Once the OID is assigned to a string, it would be bad form to change it.

Russ