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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 13 Sep 2019 12:10:49 -0700

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.

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.

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

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

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.

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

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.

   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.

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)?

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

Appendix: ASN.1 Module

   MTS-HashSig-2013

Once written, the module name can never change? :)

---

From: Russ Housley <[email-masked]>
Date: Sun, 15 Sep 2019 18:35:45 -0400

> On Sep 13, 2019, at 3:10 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

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.

> not sure why the one would be more important for correct operation than

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.

Yes.  ... with a given private key.
> 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.

> 8554 and not really avoidable in this document.

Yes. I need to be aligned with [HASHSIG].
 
> 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.

> advice about "encipherment methods are not going to make sense" might

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) }

> section as the thing being described.

It would be better to say:

> 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))

> virtual machine snapshotting or cloning, and other operational

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.

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 15 Sep 2019 21:04:26 -0500

>    the information that is needed to parse the value during signature

This is for the Section 3 text?  I think that works for me, thanks.

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

Indeed, thanks for the pointer.

> 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 norma…

Agreed; this is not the right place to do so.

Thanks for the explanation; I'll go clear now.

>    permit the registration of additional one-way hash functions in the

Sure, that takes care of the potential misread I was worried about.

>                                 -- renamed this bit to contentCommitment

That's true, but does not seem relevant to extendedKeyUsage (unless you are
saying that restrictions on keyUsage somehow supersede usage of
extendedKeyUsage?) -- I understand what we are saying about keyUsage, and
wonder if we can say anything useful about extendedKeyUsage in an analogous
fashion.

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

Okay.

>    (which MUST include a content-type attribute and a message-digest

I think my pedantic quibble ("a message-digest attribute" vs. "the
message-digest attribute [that we just talked about]") still applies to
this text, though the probability of a misreading seems low.

>    operational concerns must be considered to ensure confidentiality and

Sure, that works.

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

Is it also bad form to have the module associated with the OID change after
the OID is assigned?  (I didn't check whether this one actually changed
since 2003.)

Thanks,

Ben

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 Sep 2019 12:33:34 -0400

Ben:

Dropping the resolved parts ...

> This is for the Section 3 text?  I think that works for me, thanks.

Yes, this text goes in Section 3.

[snip]

[snip]

> wonder if we can say anything useful about extendedKeyUsage in an analogous

Because extendedKeyUsage is an object identifier, more are defined all the time, and they usually say something about protocol context.  These are defined in RFC 5280:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

   id-kp-codeSigning             OBJECT IDENTIFIER ::= { id-kp 3 }
   -- Signing of downloadable executable code
   -- Key usage bits that may be consistent: digitalSignature

   id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }
   -- Email protection
   -- Key usage bits that may be consistent: digitalSignature,
   -- nonRepudiation, and/or (keyEncipherment or keyAgreement)

So, for algorithms (without any protocol context) we only say anything about keyUsage.  You can see this in RFC 3279, Section 2.3..

Russ