Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C672D130DC1 for ; Fri, 22 Jun 2018 02:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHi1igeDNj3q for ; Fri, 22 Jun 2018 02:41:12 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9DC1274D0 for ; Fri, 22 Jun 2018 02:41:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E3C49300A08 for ; Fri, 22 Jun 2018 05:41:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ddrLsCyLS_B4 for ; Fri, 22 Jun 2018 05:41:07 -0400 (EDT) Received: from [5.5.33.206] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 73E173004B7; Fri, 22 Jun 2018 05:41:06 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_029582B2-A66D-4545-8200-91C1645FBC49" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 22 Jun 2018 05:41:06 -0400 In-Reply-To: <18F16995-D6BF-4C68-9E93-B1CF93D4369D@vigilsec.com> Cc: suit To: Tony Putman References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> <9906B2BC-BFC2-4F83-A0F6-FFCC81912237@arm.com> <140080C241BAA1419B58F093108F9EDC1E0D1690@UK-MAL-MBOX-01.dyson.global.corp> <18F16995-D6BF-4C68-9E93-B1CF93D4369D@vigilsec.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 09:41:15 -0000 --Apple-Mail=_029582B2-A66D-4545-8200-91C1645FBC49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I uses 'HSS-LMS' for the algorithm identifier. The the updates in = Sections 4 and 7... Name: draft-housley-suit-cose-hash-sig Revision: 02 Title: Use of the Hash-based Signature Algorithm with CBOR = Object Signing and Encryption (COSE) Document date: 2018-06-22 Group: Individual Submission Pages: 10 URL: = https://www.ietf.org/internet-drafts/draft-housley-suit-cose-hash-sig-02.t= xt = Status: = https://datatracker.ietf.org/doc/draft-housley-suit-cose-hash-sig/ = Htmlized: = https://tools.ietf.org/html/draft-housley-suit-cose-hash-sig-02 = Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-suit-cose-hash-sig = Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-suit-cose-hash-sig-02 = Abstract: This document specifies the conventions for using the Leighton-Micali Signature (LMS) algorithm for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax. > On Jun 22, 2018, at 5:17 AM, Russ Housley = wrote: >=20 > I was assuming that LMS would use "HASHSIG", and XMSS would use = "XMSS". These labels align with the Internet-Draft file names. In the = long run, your suggestion is probably better. >=20 > Russ >=20 >=20 >> On Jun 22, 2018, at 4:13 AM, Tony Putman > wrote: >>=20 >> As far as I can tell, it is not possible to tell from the signature = whether it is LMS or XMSS (or indeed any other hash-based signature = scheme). If this is the case, then I suggest that the algorithm = identifiers in section 4 should be more specific (e.g. 'HSIG-LMS'), as = should the COSE registry entries in section 7 (e.g. Name: HASHSIG-LMS, = with corresponding expanded description). >> -- Tony >> =20 >> From: Suit [mailto:suit-bounces@ietf.org = ] On Behalf Of Russ Housley >> Sent: 21 June 2018 20:44 >> To: Dave Thaler; Brendan Moran >> Cc: suit >> Subject: Re: [Suit] draft-housley-suit-cose-hash-sig >> =20 >> I am advocating LMS. I think it would be appropriate for an advocate = for XMSS to write a similar draft for that algorithm. >> =20 >> Russ >> =20 >>=20 >>=20 >> On Jun 21, 2018, at 12:08 PM, Dave Thaler > wrote: >> =20 >> 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. >> =20 >> 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. >> =20 >> Dave >> =20 >> From: Suit > On = Behalf Of Brendan Moran >> Sent: Thursday, June 21, 2018 9:03 AM >> To: Russ Housley > >> Cc: suit > >> Subject: Re: [Suit] draft-housley-suit-cose-hash-sig >> =20 >> Hi Russ,=20 >> 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=E2=80=99t pretend to = understand all COSE use cases. >> =20 >> Thanks, >> Brendan >>=20 >>=20 >>=20 >> On 21 Jun 2018, at 16:43, Russ Housley > wrote: >> =20 >> Brendan:=20 >> =20 >> 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. >> =20 >> This paper describes the difference between the two: >> =20 >> https://eprint.iacr.org/2017/349.pdf = >> =20 >> Russ >> =20 >>=20 >>=20 >>=20 >> On Jun 21, 2018, at 11:11 AM, Brendan Moran > wrote: >> =20 >> I see that there are two current drafts for hash-based signatures: >> https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11 = >> = https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12 = >> =20 >> 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? >> =20 >> Thanks, >> Brendan >> =20 >>=20 >>=20 >>=20 >> On 13 Jun 2018, at 20:03, Jim Schaad > wrote: >> =20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Suit > On = Behalf Of Michael Richardson >> Sent: Wednesday, June 13, 2018 11:09 AM >> To: suit > >> Subject: [Suit] draft-housley-suit-cose-hash-sig >>=20 >>=20 >> 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. >>=20 >> I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp = of >> what we are trying to plug hash-sig *into*. >>=20 >>=20 >> Suggestions: >> 1) would the structure show in section 3 be easier if it was = described by >> CDDL? I'm rather unclear about this. >>=20 >> No - this are not CBOR structures they are pure binary strings >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> o If the 'key_ops' field is present, it MUST include 'verify' >> when verifying a hash-based signature. >>=20 >> Clearly this is not something that travels over the network. Is this >> somehow >>=20 >>=20 >> indicating how to understand if one is dealing a public (verify) key = or a >> private >>=20 >>=20 >> (sign) key? >>=20 >> 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. >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> See the [HASHSIG] draft. It is encoded into the signature structure = and the >> key type is in the public key structure. >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> We have that. This is looking at a signature just like ECDSA would = produce. >> This is a different "ECDSA" replacement. >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> I would like to have some examples in CBOR/COSE worked out with = private >> keys available in the appendices. >>=20 >> Always a good thing to have. >>=20 >> Jim >>=20 >>=20 >>=20 >>=20 >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >>=20 >>=20 >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >>=20 >>=20 >> ] mcr@sandelman.ca = http://www.sandelman.ca/ = = | ruby on rails >> [ >>=20 >>=20 >>=20 >> -- >> Michael Richardson >, Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://www.ietf.org/mailman/listinfo/suit = >> =20 >> 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. >> =20 >> =20 >> 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. >> =20 >>=20 >> Dyson Technology Limited, company number 01959090, Tetbury Hill, = Malmesbury, SN16 0RP, UK.=20 >> This message is intended solely for the addressee and may contain = confidential information. If you have received this message in error, = please immediately and permanently delete it, and do not use, copy or = disclose the information contained in this message or in any attachment.=20= >> Dyson may monitor email traffic data and content for security & = training. >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit --Apple-Mail=_029582B2-A66D-4545-8200-91C1645FBC49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I uses 'HSS-LMS' for the algorithm identifier.  The the = updates in Sections 4 and 7...

Name: draft-housley-suit-cose-hash-sig
Revision: 02
Title: Use of the Hash-based Signature = Algorithm with CBOR Object Signing and Encryption (COSE)
Document date: 2018-06-22
Group: Individual Submission
Pages: 10
URL: =            https://www.ietf.org/internet-drafts/draft-housley-suit-cose-ha= sh-sig-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-housley-suit-cose-hash-s= ig/
Htmlized:       https://tools.ietf.org/html/draft-housley-suit-cose-hash-sig-02=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-suit-cose-h= ash-sig
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-suit-cose-has= h-sig-02

Abstract:
  This document specifies the conventions for using = the Leighton-Micali
  Signature (LMS) algorithm = for digital signatures with the CBOR Object
  Signing and Encryption (COSE) syntax.

On Jun 22, 2018, at 5:17 AM, Russ Housley <housley@vigilsec.com> wrote:

I was assuming that = LMS would use "HASHSIG", and XMSS would use "XMSS".  These labels = align with the Internet-Draft file names.  In the long run, your = suggestion is probably better.

Russ


On Jun = 22, 2018, at 4:13 AM, Tony Putman <Tony.Putman@dyson.com> wrote:

As far as I can tell, it is not possible to tell = from the signature whether it is LMS or XMSS (or indeed any other = hash-based signature scheme). If this is the case, then I suggest that = the algorithm identifiers in section 4 should be more specific (e.g. = 'HSIG-LMS'), as should the COSE registry entries in section 7 (e.g. = Name: HASHSIG-LMS, with corresponding expanded description).
-- Tony
 
From: Suit [mailto:suit-bounces@ietf.org] On Behalf = Of Russ Housley
Sent: 21 June 2018 20:44
To: Dave Thaler; Brendan = Moran
Cc: suit
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 <dthaler@microsoft.com> = 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 <suit-bounces@ietf.org> On Behalf = Of Brendan = Moran
Sent: Thursday, June 21, 2018 = 9:03 AM
To: Russ Housley <housley@vigilsec.com>
Cc: suit = <suit@ietf.org>
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=E2=80=99t pretend to understand all COSE = use cases.
 
Thanks,
Brendan



On 21 Jun 2018, at 16:43, Russ Housley <housley@vigilsec.com> 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:
 
 
Russ
 



On Jun 21, 2018, at 11:11 AM, Brendan Moran <Brendan.Moran@arm.com> wrote:
 
I see that there are two current drafts for hash-based = signatures:
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-sig= natures-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 <ietf@augustcellars.com> = wrote:
 




-----Original = Message-----
From: Suit <suit-bounces@ietf.org> On Behalf Of Michael = Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <suit@ietf.org>
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
          &nb= sp;     creating a hash-based signature.

     o  If the = 'key_ops' field is present, it MUST include 'verify'
          &nb= sp;     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




--
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh
networks [


]   Michael = Richardson, Sandelman Software Works =        | network
architect =  [


] =     mcr@sandelman.ca  http://www.sandelman.ca/      = ;  |   ruby on rails
[



--
Michael = Richardson <mcr+IETF@sandelman.ca>, Sandelman = Software Works
-=3D IPv6 IoT consulting =3D-




_______________________________________________
Suit mailing list
Suit@ietf.org
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.
 

Dyson Technology Limited, company = number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK. 
This message = is intended solely for the addressee and may contain confidential = information. If you have received this message in error, please = immediately and permanently delete it, and do not use, copy or disclose = the information contained in this message or in any attachment. 
Dyson may = monitor email traffic data and content for security & = training.

_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit

= --Apple-Mail=_029582B2-A66D-4545-8200-91C1645FBC49--