Subject: [COSE] Comments on draft-ietf-cose-hash-sig-01

From: John Mattsson <[email-masked]>
Date: Thu, 21 Mar 2019 19:40:40 +0000

Hi,

Some high level comments below. I need to read draft-mcgrew-hash-sigs in more detail before giving more comments. 

- Section 1.1: I think some short info on the threat from Shor's algorithm would be good. I don't think [BH2013] talked about quantum computers.

- Section 1.1: "RSA, DSA, and ECDSA are not post-quantum secure"
Add EdDSA to the list.

- Section 1.1 " depend on discrete logarithm or factoring"
I suggestion "depend on the hardness of ... " or something similar.

 - "The CBOR Object Signing and Encryption (COSE) [RFC8152] supports two
   signature algorithm schemes."

    With RSA it is already three. Maybe remove this sentence?

-  The other COSE Key types define how the the private and public key is stored in the COSE_Key structure. The HSS-LMS key type does not seem to do that, instead it only works as an identifier of the public/private key. I think the document should either

       - Define how to store the public key in the COSE_Key structure, or

       - Describe that the HSS-LMS key type is only an identifier and does not store the key pair. In that case I think the
         description "Description:  Public key for HSS/LMS hash-based digital signature" should be changed as well to
          include the word "identifier".

- As the algorithm and COSE_Key only contains the information "HSS-LMS@ and no information regarding the tree size and LM-OTS variant I assume the signer and verifier gets this information elsewhere (or does not need it). I think it would good if the draft shortly clarified this.

Nits:

"{{SHS}}"

Cheers,
John

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Mar 2019 21:51:54 -0400

> - Section 1.1: I think some short info on the threat from Shor's algorithm would be good. I don't think [BH2013] talked about quantum computers.

Right.  [BH2013] is about advances in cryptanalysis. [PQC] is about the consequences of a large-scale quantum computer.  I suggest:

   If large-scale quantum computers are ever built, these computers will
   be able to break many of the public-key cryptosystems currently in
   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
   feasible to build such computers; however, RSA, DSA, ECDSA, and EdDSA
   are all vulnerable if large-scale quantum computers come to pass.

> - Section 1.1: "RSA, DSA, and ECDSA are not post-quantum secure"

As above.

> I suggestion "depend on the hardness of ... " or something similar.

Yes, indeed.  I suggest:

   The HSS/LMS signature algorithm does not depend on the difficulty of
   discrete logarithm or factoring, as a result these algorithms are
   considered to be post-quantum secure.

>    With RSA it is already three. Maybe remove this sentence?

I am not talking about algorithms here.  I am talking about full signature and COSE_Sign0.

>          include the word "identifier".

Okay.  The public key is an octet string.  The internal structure of that octet string is summarized in Section 2.2, and it is fully specified in [HASHSIG].  Also, the IANA Considerations include a new entry in the "COSE Key Types" registry for the HSS/LMS public key.

> - As the algorithm and COSE_Key only contains the information "HSS-LMS@ and no information regarding the tree size and LM-OTS variant I assume the signer and verifier gets this information elsewher…

The signature value encodes that information as summarized in Section 2, and it is fully specified in [HASHSIG].

> "{{SHS}}"

Fixed.

Russ

---

From: John Mattsson <[email-masked]>
Date: Fri, 22 Mar 2019 10:25:59 +0000

Thanks Russ,

Your suggested updates seems great.

>I am not talking about algorithms here.  I am talking about full signature and COSE_Sign0.

Ok, I see that the terminology is taken from Section 8 of RFC 8152:

   There are two signature algorithm schemes.  The first is signature
   with appendix.  In this scheme, the message content is processed and
   a signature is produced; the signature is called the appendix.  This
   is the scheme used by algorithms such as ECDSA and the RSA
   Probabilistic Signature Scheme (RSASSA-PSS).  (In fact, the SSA in
   RSASSA-PSS stands for Signature Scheme with Appendix.)

I do however find the terminology quite confusing as the term "scheme" is used on different levels. But that is more a comment for draft-ietf-cose-rfc8152bis-struct than draft-ietf-cose-hash-sig.

>The signature value encodes that information as summarized in Section 2, and it is fully specified in [HASHSIG].

I have no doubt that the specification is correct, and that everything is fully specified in [HASHSIG]. BTW, Sections 2.1 - 2.3 give an excellent summary of HASHSIG. My feeling was just that some more short high level description would be helpful for developers implementing the draft. Such a developer would likely not have any understanding of [HASHSIG] and would likely take a [HASHSIG] implementation from the Internet and try to integrate it in their COSE implementation. Even for a developer that has previously implemented ECDSA or RSA signatures, [HASHSIG] works quite different as there are many public/private keys pairs and the public/private key pairs are not stored in the COSE_Key structure as with RSA and ECDSA.

I think it would be good if the draft gave some more guidance to a developer trying to integrate an existing HASHSIG library in their COSE implementation. But that is just a suggestion. I do not have strong feelings about this. I have not tried to actually implement it, and I do not yet have the detailed knowledge of HASHSIG to suggest what such guidance would actually say.

Cheers,
John

-----Original Message-----
From: Russ Housley <[email-masked]>
Date: Friday, 22 March 2019 at 07:40
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [COSE] Comments on draft-ietf-cose-hash-sig-01

    

    
    As above.

    Yes, indeed.  I suggest:

    

    

    
    Fixed.
    
    Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Mar 2019 06:32:58 -0400

John:

Thanks for the review and continued dialogue.

> I do however find the terminology quite confusing as the term "scheme" is used on different levels. But that is more a comment for draft-ietf-cose-rfc8152bis-struct than draft-ietf-cose-hash-sig.

I am pleased to align with whatever term gets used in rfc8152bis.

> I think it would be good if the draft gave some more guidance to a developer trying to integrate an existing HASHSIG library in their COSE implementation. But that is just a suggestion. I do not ha…

I want to help implementations, but I am not sure what else to say here.  The HSS/LMS public key appears at the apex of the tree.

Russ