Re: [lamps] Question on draft-ietf-lamps-cms-hash-sig

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

From: Jim Schaad <[e-mail]>
Sent: Monday, March 18, 2019 4:19 PM
To: Scott Fluhrer (sfluhrer) <[e-mail]>; 'Daniel Van Geest' <[e-mail]>; 'Russ Housley' <[e-mail]>
Cc: 'SPASM' <[e-mail]>; [e-mail]
Subject: RE: [lamps] Question on draft-ietf-lamps-cms-hash-sig



From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Monday, March 18, 2019 2:21 PM
To: Daniel Van Geest <[e-mail]<mailto:[e-mail]>>; Jim Schaad <[e-mail]<mailto:[e-mail]>>; 'Russ Housley' <[e-mail]<mailto:[e-mail]>>
Cc: 'SPASM' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [lamps] Question on draft-ietf-lamps-cms-hash-sig



From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Daniel Van Geest
Sent: Monday, March 18, 2019 1:58 PM
To: Jim Schaad <[e-mail]<mailto:[e-mail]>>; 'Russ Housley' <[e-mail]<mailto:[e-mail]>>
Cc: 'SPASM' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [lamps] Question on draft-ietf-lamps-cms-hash-sig



On 2019-03-17, 7:39 AM, "Jim Schaad" <[e-mail]<mailto:[e-mail]>> wrote:

I don’t know what Jim is arguing.  I think that I am trying to say that there may be some language that is not clear at some point in the future although it is perfectly fine today (mostly).  I do not remember ever seeing any language in any of the hash signature documents that say that the same hash function should be used from top to bottom.  I also think that there will be some push in the not so near future to have some other hash functions be permitted because of things like the better efficiency of SHA-512 in many cases or the move to SHAKE as a different hash function.  I worry that this means that the same hash function may not be used from top to bottom in a hash signature key.  I also worry that my current code base does not have any way to get the parameters for the bottom of the tree and the same thing may be true for an HSM.  The top algorithms can be retrieved from the public key, but not the bottom algorithms.

My colleagues have had similar concerns and we have raised them privately.  But the fact that the parameters are encoded in a signature means you can still verify the signature regardless of whether the parameters are in the public key.  And since the parameters could theoretically be changed as trees are used up they can’t be encoded with the public key (unless the use of HSS in CMS/X.509 specified that the parameters can’t change, which would be okay with me).

Actually, there is text in the LMS draft (which is becoming an RFC Real Soon Now) specifically forbidding changing the parameters on the fly…

[JLS] So we have the ability to have different parameters at each level from the beginning, but one is not supposed to change them when a new subtree is created.  I don’t remember seeing that and will look

Here’s the text (at the end of section 6); the wording is slightly different from the current draft (due to AUTH48 edits), but the meaning is the same:

   A close reading of the HSS verification pseudocode would show that it
   would allow the parameters of the nontop LMS public keys to change
   over time; for example, the signer might initially have the 1-th LMS
   public key use the LMS_SHA256_M32_H10 parameter set, but when that
   tree is exhausted, the signer might replace it with an LMS public key
   that uses the LMS_SHA256_M32_H15 parameter set.  While this would
   work with the example verification pseudocode, the signer MUST NOT
   change the parameter sets for a specific level.  This prohibition is
   to support verifiers that may keep state over the course of several
   signature verifications.



As for it being the same for HSMs, they could encode the parameters with their private key & state however they like.  IMO we shouldn’t standardize how to encode the private key since that implies replicating or moving it around, which will invariably be done wrong causing state to be reused, allowing forgeries.

Jim


From: Russ Housley <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, March 16, 2019 4:33 PM
To: Daniel Van Geest <[e-mail]<mailto:[e-mail]>>
Cc: Jim Schaad <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; SPASM <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lamps] Question on draft-ietf-lamps-cms-hash-sig

Daniel:

I believe that Jim is arguing that the same hash function should always be used for both the content and the HSS/LMS tree,

Russ


On Mar 15, 2019, at 3:30 PM, Daniel Van Geest <[e-mail]<mailto:[e-mail]>> wrote:

My thoughts,

On 2019-03-14, 2:39 PM, "Spasm on behalf of Jim Schaad" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

I was tossing together some code to look at producing some samples and I
ended up with a pair of questions:

1.  If I have a hash signature tree which uses multiple different hash
algorithms in it, which of those hash algorithms am I to placed in the
digestAlgorithm field?  For example, suppose that I am using an LMS type
with a hash of SHAKE128 and an LMOTS type with a hash of SHA256.  Or as a
different example, suppose that I have a two deep tree and the top level
uses SHA512 in both places but the next level down uses SHAH256 in both
places?

RFC 5652 section 5.3 defines the digestAlgorithm member of SignerInfo as:
      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the signer.  The message digest is
      computed on either the content being signed or the content
      together with the signed attributes using the process described in
      Section 5.4.

In HSS, the hash algorithm used to digest the content is the one in the LMOTS type of the bottom-most tree.  The other hash algorithms are used to hash within the Merkle tree, or to hash the LMS public key of a lower tree.  So in both your examples the answer would be SHA256.

2.  If there are signed attributes present, then it t required that the body
digest algorithm match that of the hash signature tree or can it be
different.  If it is different, is that not the value that should be placed
in the digestAlgorithm field?  Consider digesting the body with SHA512, but
only using SHA256 in the hash function on the assumption that the random
field in the signing operation provides a higher level of security and thus
a weak attempt is being made to match them together.  (I am sure that this
is not the correct pairing for matching, just demonstrating a point.)

cms-hash-sigs says:
      digestAlgorithm MUST contain the one-way hash function used to in
         the HSS/LMS tree.
This statement plus the one I quoted from RFC 5652 would imply that the body digest algorithm must match that of the HSS algorithm.

However, you are correct that the random field added during signing increases the collision resistance of the signature and so using the same algorithm to create the message-digest attribute in the signed attributes would reduce the collision resistance of the system.  If you wanted to allow a different hash algorithm in the signed attributes message digest, I think cms-hash-sigs would need to be modified to further specify signed-data conventions with/without signed attributes, similar to RFC 8419.

Daniel

Jim


_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spasm