Re: [Suit] draft-housley-suit-cose-hash-sig

[Jim Schaad <[e-mail]>]

I have not looked in detail at the XMSS signature structure  and key structure and would want to do so before making any type of definitive statement.  However different drafts defining the different signature structures is what I would generally expect unless there is a huge overlap between them.  I would guess that the key structures are also different and thus would probably need to be identified differently.  This is based on the fact that a algorithm variant byte is placed at the start of both the key and signatures.

 

Doing this separately when we know they are going to be used (or potentially used) makes more sense to me.

 

Jim

 

 

From: Suit <[e-mail]> On Behalf Of Russ Housley
Sent: Thursday, June 21, 2018 12:44 PM
To: Dave Thaler <[e-mail]>; Brendan Moran <[e-mail]>
Cc: suit <[e-mail]>
Subject: Re: [Suit] draft-housley-suit-cose-hash-sig

 

I am advocating LMS. I think it would be appropriate for an advocate for XMSS to write a similar draft for that algorithm.

 

Russ

 





On Jun 21, 2018, at 12:08 PM, Dave Thaler <[e-mail] <mailto:[e-mail]> > wrote:

 

This is similar to a question I asked as well, whether the IETF only needs LMS or whether LMS is just an instance in a larger class that might be needed, and what the scope of the draft should be.

 

If the draft is not SUIT-only (e.g., allowing use in OSCORE, etc.) then it sounds like we might need the ability to support more than LMS for some use cases.

 

Dave

 

From: Suit < <mailto:[e-mail]> [e-mail]> On Behalf Of Brendan Moran
Sent: Thursday, June 21, 2018 9:03 AM
To: Russ Housley < <mailto:[e-mail]> [e-mail]>
Cc: suit < <mailto:[e-mail]> [e-mail]>
Subject: Re: [Suit] draft-housley-suit-cose-hash-sig

 

Hi Russ, 

Thanks for the clarification. I agree that a larger signature is not what we need in SUIT. However, for the COSE draft, would it not make sense to provide for both LMS and XMSS? I don’t pretend to understand all COSE use cases.

 

Thanks,

Brendan






On 21 Jun 2018, at 16:43, Russ Housley < <mailto:[e-mail]> [e-mail]> wrote:

 

Brendan: 

 

Yes, there are two CFRG algorithms for hash-based signatures.  I prefer the one McGrew's document, mostly because it is more straightforward.  There is some speed improvement for the additional complexity in XMSS at the cost of a larger signature value.  To me, the speed improvement is not big enough to justify the larger signature size.  Your mileage may vary.

 

This paper describes the difference between the two:

 

 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2017%2F349.pdf&data=02%7C01%7Cdthaler%40microsoft..com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771383092&sdata=zDGqR2NskjJzyVVcCEg8suPo3Lt9b6xLI1lxaYlWrbQ%3D&reserved=0> https://eprint.iacr.org/2017/349.pdf

 

Russ

 






On Jun 21, 2018, at 11:11 AM, Brendan Moran < <mailto:[e-mail]> [e-mail]> wrote:

 

I see that there are two current drafts for hash-based signatures:

 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mcgrew-hash-sigs-11&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771393097&sdata=CTRx3BW3duXIREYxP4CyR%2BQY63qYgi2vqjnUM9uKqQM%3D&reserved=0> https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11

 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-cfrg-xmss-hash-based-signatures-12&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771393097&sdata=pii%2Boa8SkTt7PLarq0P%2FKXL4WBVpNwLzGSIxEgZG5YU%3D&reserved=0> https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12

 

I see that you have referenced the mcgrew draft rather than the IRTF/CFRG draft. Could you please explain what the difference is between these two drafts and why the mcgrew draft was a better choice than XMSS?

 

Thanks,

Brendan

 






On 13 Jun 2018, at 20:03, Jim Schaad < <mailto:[e-mail]> [e-mail]> wrote:

 







-----Original Message-----
From: Suit < <mailto:[e-mail]> [e-mail]> On Behalf Of Michael Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit < <mailto:[e-mail]> [e-mail]>
Subject: [Suit] draft-housley-suit-cose-hash-sig


I have read the -01 draft today.
I have not read [HASHSIG] yet.
I thought I'd try reading this first, to see what questions I had.

I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of
what we are trying to plug hash-sig *into*.


Suggestions:
1) would the structure show in section 3 be easier if it was described by
  CDDL?  I'm rather unclear about this.


No - this are not CBOR structures they are pure binary strings






2) I din't understand section 4, where it says:
     o  If the 'key_ops' field is present, it MUST include 'sign' when
                creating a hash-based signature.

     o  If the 'key_ops' field is present, it MUST include 'verify'
                when verifying a hash-based signature.

Clearly this is not something that travels over the network.  Is this

somehow




indicating how to understand if one is dealing a public (verify) key or a

private




(sign) key?


The key_ops field can be considered to potentially be transported over a
network.  It is part of the COSE_Key object rather than part of the
COSE_Sign1 object.






3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2,
etc. are
  listed, but I don't know if they need to be carried in the signature
  structure somehow.


See the [HASHSIG] draft.  It is encoded into the signature structure and the
key type is in the public key structure.






4) I thought that perhaps we'd need CBOR or COSE specific way to transport
  the signatures.  I guess I shall read HASHSIG to find out what the
  signatures look like.


We have that.  This is looking at a signature just like ECDSA would produce.
This is a different "ECDSA" replacement.






I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG.
I believe that SUIT should adopt this document, and should do so in the
current state.

I would like to have some examples in CBOR/COSE worked out with private
keys available in the appendices.


Always a good thing to have.

Jim






--
]               Never tell me the odds!                 | ipv6 mesh

networks [




]   Michael Richardson, Sandelman Software Works        | network

architect  [




]      <mailto:[e-mail]> [e-mail]   <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771403102&sdata=M7Tnkm9SzFy0ImJTiHRTBVDGfi3pR1vFixMCWskWmOo%3D&reserved=0> http://www.sandelman.ca/        |   ruby on rails

[





--
Michael Richardson < <mailto:[e-mail]> [e-mail]>, Sandelman Software Works
-= IPv6 IoT consulting =-






_______________________________________________
Suit mailing list
 <mailto:[e-mail]> [e-mail]
 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771403102&sdata=AKEzjOXtE%2FPSc%2FbwKUP0ctCmYNL4CLWNuF9hh7IzOxE%3D&reserved=0> https://www.ietf.org/mailman/listinfo/suit

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.