Subject: Re: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 14 Feb 2019 22:37:57 +0000

Sorry for being late, but I was just re-reviewing the draft, and I noticed something odd:

You define id-alg-hss-lms-hashsig-with-sha384 (and sha512); with the comment that this specifies the use SHA-384 to hash the content.

That’s not how LMS is designed to work; currently, it uses the same hash function to hash the message as it does for all its internal hashes.  If you were to replace the initial SHA-256 hash with something larger, well, you’d need to tweak the size of the LM-OTS signature (to accomendate the larger value being signed), and so that wouldn’t be clean at all.

For that matter, iLMS doesn’t do a straight hash of the message; instead, it includes a prefix (the point of the prefix, which is randomized, is to avoid relying on the collision resistance of SHA-256).

Now, I suppose you could SHA-384 hash the message, and then turn around and do an LMS signature generate/verify on that hash (which would, with the currently defined LMS parameter sets, immediately prepend the prefix, and that SHA-256 hash it).  However, if something that nonobvious is specified, you need to call it out explicitly (and also what do you do with id-alg-hss-lms-hashsig-with-sha256; would that also do an initial SHA-256 hash?).

My suggestion would be to combine all three algorithm identifiers into a single id-alg-hssms-hashsig (and have the parameter set indicator within the LMS public key specify which hash is to be used).

And, since someone brought up XMSS, well, that’d have pretty much the same issues (and for the same reasons…)

From: Russ Housley <[email-masked]>
Sent: Thursday, January 31, 2019 11:07 AM
To: Scott Fluhrer (sfluhrer) <[email-masked]>
Cc: Tim Hollebeek <[email-masked]>; SPASM <[email-masked]>
Subject: Re: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03

Scott:

Thanks for the careful read.  I have made these changes in my edit buffer.

Russ

On Jan 30, 2019, at 3:04 PM, Scott Fluhrer (sfluhrer) <[email-masked]<mailto:[email-masked]>> wrote:

Just two spelling corrections…

Nit: in the first line of section 4: “for an HHS/LMS public key” should be “for an HSS/LMS public key”

Nit: in the first line of section 6.2: “on the current sate” should be “on the current state”

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Tim Hollebeek
Sent: Wednesday, January 30, 2019 2:25 PM
To: SPASM <[email-masked]<mailto:[email-masked]>>
Subject: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03

This is the LAMPS WG Last Call for “Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS)” <draft-ietf-lamps-cms-hash-sig-03>.

Please review the document and send your comments to the list by 14 February 2019.

If no concerns are raised, the document will be forwarded to the IESG with a request for publication as Proposed Standard.

-Tim

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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 14 Feb 2019 20:52:28 -0800

Scott,

The way that this is written has to do to a degree with how CMS works and how most people think of signature algorithms as working.  I have also raised this point of doing a direct signature of the “message” (which is not necessarily the message content) without going through an extra hash function.   If you think about what happens for RSA with SHA-384, then you can see that the message needs to be hashed before the RSA operation can be applied.  As you noted, this is not necessary for any of the hash signature algorithms as there is no practical maximum message length that would be hashed.  

My preference would be to have a version which is just id-alg-hss-lms-hashsig-direct which does not do that extra hash operation and I have requested that this happens, but it has not been done at present.

I believe that your position would really translate to support of my position.

Jim

From: Spasm <[email-masked]> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Thursday, February 14, 2019 2:38 PM
To: Russ Housley <[email-masked]>
Cc: SPASM <[email-masked]>; Tim Hollebeek <[email-masked]>
Subject: Re: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03

From: Russ Housley <[email-masked] <mailto:[email-masked]> > 
Sent: Thursday, January 31, 2019 11:07 AM
To: Scott Fluhrer (sfluhrer) <[email-masked] <mailto:[email-masked]> >
Cc: Tim Hollebeek <[email-masked] <mailto:[email-masked]> >; SPASM <[email-masked] <mailto:[email-masked]> >
Subject: Re: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03

Scott:

Russ

On Jan 30, 2019, at 3:04 PM, Scott Fluhrer (sfluhrer) <[email-masked] <mailto:[email-masked]> > wrote:

 

From: Spasm < <mailto:[email-masked]> [email-masked]> On Behalf Of Tim Hollebeek
Sent: Wednesday, January 30, 2019 2:25 PM
To: SPASM < <mailto:[email-masked]> [email-masked]>
Subject: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03

-Tim

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 18 Feb 2019 12:39:10 -0500

> That’s not how LMS is designed to work; currently, it uses the same hash function to hash the message as it does for all its internal hashes.  If you were to replace the initial SHA-256 hash with s…

Thanks for taking another look.  I am glad that you did!

You are correct that draft-ietf-lamps-cms-hash-sig-01 did not include AlgorithmIdentifiers for signatures with any hash function other than SHA-256.  They were added in -02 in response to comments.

There are two cases to consider when signing with CMS:

1) When signed attributes are absent: the signer hashes the content, and then signs the resulting message digest.

2) When signed attributes are present: the signer hashes the content and places the resulting message digest in the message-digest attribute, DER-encodes the set of signed attributes, hashes the encoded attributes, and then signs the resulting message digest.

It was observed that the hash of the content is the weakest link because the HSS/LMS signature calculation includes a random value, C.  The thought was to allow the larger hash value to compensate.

(See https://mailarchive.ietf.org/arch/msg/spasm/cXkpVmAnfFwfp6MxgUHJWjSMHZw <https://mailarchive.ietf.org/arch/msg/spasm/cXkpVmAnfFwfp6MxgUHJWjSMHZw>)

> My suggestion would be to combine all three algorithm identifiers into a single id-alg-hssms-hashsig (and have the parameter set indicator within the LMS public key specify which hash is to be used…

I realize the hash function identifier for the HSS/LMS tree(s) is embedded in the signature value itself.  The reason for the hash function identifier in the OID is explained above.

If others are comfortable requiring that the same hash function is used throughout, then we can collapse back to one algorithm identifier.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Mon, 18 Feb 2019 10:45:01 -0800

Russ,

In the message below I am getting confused about what hash is being used for what and where it is being identified.

Case #1 – No signed attributes

HashContent = H1(content)

Signature = HSS-Sign(key, HashContent)

Case #2 – Signed Attributes

HashContent = H1(content)

SignerInfo = <digestAlgorithm = H1, signedAttributes=<MessageDigest=HashContent>>

Signature = HSS-Sign(key, H2(signedAttributes))

The hash algorithm identified in the signature algorithm OID is H1 for case #1 and H2 for case #2.  (Note: I want these hash algorithms to be identity.)

In addition there is a third hash algorithm H3 which is the hash algorithm used for the one-time-signature.  Note that there may be other hash algorithms H4….Hn as the hash algorithm at each layer in the HSS tree could be using a different hash algorithm.

When you say that you want to use the same hash algorithm consistently through all of the processing, what hash algorithms are you talking about?  

jim

From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Monday, February 18, 2019 9:39 AM
To: Scott Fluhrer <[email-masked]>
Cc: SPASM <[email-masked]>
Subject: Re: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03

Scott:

(See https://mailarchive.ietf.org/arch/msg/spasm/cXkpVmAnfFwfp6MxgUHJWjSMHZw)

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Feb 2019 16:14:11 -0500

Jim and Scott:

Instead of saying what the current draft says, let's focus on what we want it to say.

I think that the draft can be less complex.  In all cases,

(1) the digestAlgorithm in SignerInfo MUST be set to the hash algorithm used in the HSS/LMS tree, which is currently only SHA-256; and

(2) the signatureAlgorithm  in SignerInfo MUST contain id-alg-hss-lms-hashsig.  Note that the "with-sha256" is removed.  The hash function used by the signer can be learned from the digestAlgorithm or from the signature value itself.

Then, we need to specify two cases:

Case #1 -- No signed attributes -- the HSS/LMS signature is computed over the content as specified in [HASHSIG].

Case #2 -- Signed Attributes -- there are a few steps:

(a) compute a hash over the content using the hash function identified in digestAlgorithm:

	HashContent = H(content)

(b) gather all of the attributes to be signed, which MUST include a content-type attribute and a message-digest attribute.  Then, DER encode the set of attributes.

	DER(SET(attr1, attr2, ...))

(c) the HSS/LMS signature is computed over the output of the DER encode operation as specified in [HASHSIG].

Does this address all of the comments that have been raised to date?

Russ

> On Feb 18, 2019, at 1:45 PM, Jim Schaad <[email-masked]> wrote:
> 
> Russ,
>  
> From: Spasm <[email-masked] <mailto:[email-masked]>> On Behalf Of Russ Housley
> To: Scott Fluhrer <[email-masked] <mailto:[email-masked]>>
> Cc: SPASM <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: Jim Schaad <[email-masked]>
Date: Fri, 22 Feb 2019 14:18:58 -0800

Yes I think that this is what the document needs to say.

From: Russ Housley <[email-masked]> 
Sent: Friday, February 22, 2019 1:14 PM
To: Jim Schaad <[email-masked]>; Scott Fluhrer <[email-masked]>
Cc: SPASM <[email-masked]>
Subject: Re: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03

Jim and Scott:

              HashContent = H(content)

Russ

On Feb 18, 2019, at 1:45 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

Russ,

jim

From: Spasm < <mailto:[email-masked]> [email-masked]> On Behalf Of Russ Housley
Sent: Monday, February 18, 2019 9:39 AM
To: Scott Fluhrer < <mailto:[email-masked]> [email-masked]>
Cc: SPASM < <mailto:[email-masked]> [email-masked]>
Subject: Re: [lamps] Last Call: draft-ietf-lamps-cms-hash-sig-03

Scott:

(See  <https://mailarchive.ietf.org/arch/msg/spasm/cXkpVmAnfFwfp6MxgUHJWjSMHZw> https://mailarchive.ietf.org/arch/msg/spasm/cXkpVmAnfFwfp6MxgUHJWjSMHZw)

Russ