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

From: Jim Schaad <[email-masked]>
Date: Thu, 14 Mar 2019 11:39:27 -0700

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?  

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

Jim

---

From: Daniel Van Geest <[email-masked]>
Date: Fri, 15 Mar 2019 19:30:46 +0000

My thoughts,

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

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.

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Sat, 16 Mar 2019 19:33:13 -0400

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 <[email-masked]> wrote:
> 
> My thoughts,
>  
> On 2019-03-14, 2:39 PM, "Spasm on behalf of Jim Schaad" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: Daniel Van Geest <[email-masked]>
Date: Sun, 17 Mar 2019 06:47:02 +0000

That would simplify things, and despite the collision resistance reduction, should be "good enough" against a quantum attacker due to properties of Grover's algorithms like parallallizing poorly. I think we may still mention things like this in the security considerations of the x509-hash-sigs draft despite no longer proposing pre-hashed OIDs.

Daniel

From: [email-masked]
Sent: March 17, 2019 12:33 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lamps] Question on draft-ietf-lamps-cms-hash-sig

Daniel:

Russ

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

My thoughts,

cms-hash-sigs says:

Daniel

Jim

---

From: Jim Schaad <[email-masked]>
Date: Sun, 17 Mar 2019 04:39:13 -0700

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.

Jim

From: Russ Housley <[email-masked]> 
Sent: Saturday, March 16, 2019 4:33 PM
To: Daniel Van Geest <[email-masked]>
Cc: Jim Schaad <[email-masked]>;
[email-masked]; SPASM <[email-masked]>
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 <[email-masked]
<mailto:[email-masked]> > wrote:

My thoughts,

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

places?  

      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.

cms-hash-sigs says:

         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:[email-masked]> [email-masked]

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

---

From: Daniel Van Geest <[email-masked]>
Date: Mon, 18 Mar 2019 17:58:17 +0000

On 2019-03-17, 7:39 AM, "Jim Schaad" <[email-masked]<mailto:[email-masked]>> 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).

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

Cc: Jim Schaad <[email-masked]>; [email-masked]; SPASM <[email-masked]>

Daniel:

Russ

My thoughts,

cms-hash-sigs says:

Daniel

Jim

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 18 Mar 2019 18:21:26 +0000

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

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

Jim

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

Daniel:

Russ

My thoughts,

cms-hash-sigs says:

Daniel

Jim

---

From: Jim Schaad <[email-masked]>
Date: Mon, 18 Mar 2019 16:18:49 -0400

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

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

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

[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

Jim

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

Daniel:

Russ

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

My thoughts,

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

places?  

      Section 5.4.

cms-hash-sigs says:

         the HSS/LMS tree.

Daniel

Jim

Spasm mailing list

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

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 18 Mar 2019 20:54:45 +0000

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

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

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

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.

Jim

Daniel:

Russ

My thoughts,

cms-hash-sigs says:

Daniel

Jim

---

From: Jim Schaad <[email-masked]>
Date: Tue, 19 Mar 2019 08:11:58 +0100

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

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

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

 

   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.

Jim

Daniel:

Russ

My thoughts,

places?  

      Section 5.4.

cms-hash-sigs says:

         the HSS/LMS tree.

Daniel

Jim

Spasm mailing list

---

From: Jim Schaad <[email-masked]>
Date: Tue, 19 Mar 2019 08:15:50 +0100

From: Daniel Van Geest <[email-masked]> 
Sent: Monday, March 18, 2019 6:58 PM
To: Jim Schaad <[email-masked]>; 'Russ Housley' <[email-masked]>
Cc: [email-masked]; 'SPASM' <[email-masked]>
Subject: Re: [lamps] Question on draft-ietf-lamps-cms-hash-sig

[JLS} I am not advocating that the private key be standardized at this point, although I think that there might be some requirements for it at some point, I am worried that the API to the HSM needs to have a function which says – For this hash signature key, return the LMOTS algorithm at the bottom of the stack. – This is not something that is highlighted anyplace and therefore will likely not occur especially as currently it is not required since the answer can be hard coded to SHA-256.

Jim

Daniel:

Russ

My thoughts,

places?  

      Section 5.4.

cms-hash-sigs says:

         the HSS/LMS tree.

Daniel

Jim

Spasm mailing list