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

[Benjamin Kaduk <[e-mail]>]

On Sun, Sep 15, 2019 at 06:35:45PM -0400, Russ Housley wrote:
> 
> 
> > 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.

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

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

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

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

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

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

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

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

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

Okay.

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

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.

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

Sure, that works.

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

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