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

[Jim Schaad <[e-mail]>]

 

 

From: Spasm <[e-mail]> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Monday, March 18, 2019 9:55 PM
To: Jim Schaad <[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: Jim Schaad <[e-mail] <mailto:[e-mail]> > 
Sent: Monday, March 18, 2019 4:19 PM
To: Scott Fluhrer (sfluhrer) <[e-mail] <mailto:[e-mail]> >; 'Daniel Van Geest' <[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 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.

 

[JLS] I suppose that I like the fact that the parameters are not going to change, but the only state that one could keep across a sub-tree being regenerated would be the size of the sub-tree.  All of the cached verification data from that point down would be rendered moot by the fact that a new sub-tree has been generated.  That said I have no problems with making this a requirement.

 

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" < <mailto:[e-mail]> [e-mail] on behalf of  <mailto:[e-mail]> [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

 <mailto:[e-mail]> [e-mail]

 <https://www.ietf.org/mailman/listinfo/spasm> https://www.ietf.org/mailman/listinfo/spasm