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 EDD6A130EC5 for ; Thu, 21 Jun 2018 12:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 CjZ4F8qJxHZh for ; Thu, 21 Jun 2018 12:43:55 -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 C8A2A130DFA for ; Thu, 21 Jun 2018 12:43:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AC738300557 for ; Thu, 21 Jun 2018 15:43:52 -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 bmxiegFBnnKi for ; Thu, 21 Jun 2018 15:43:49 -0400 (EDT) Received: from new-host-4.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id B1998300433; Thu, 21 Jun 2018 15:43:49 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A848FCD0-E45D-4BCE-B424-852D2958D8E5" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 21 Jun 2018 15:43:50 -0400 In-Reply-To: Cc: suit To: Dave Thaler , Brendan Moran 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> 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: Thu, 21 Jun 2018 19:43:59 -0000 --Apple-Mail=_A848FCD0-E45D-4BCE-B424-852D2958D8E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = 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 > 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 > 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 > On 13 Jun 2018, at 20:03, Jim Schaad > wrote: > =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 > 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 > indicating how to understand if one is dealing a public (verify) key = or a > private >=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 > 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 > 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 > 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 > -- > ] Never tell me the odds! | ipv6 mesh > networks [ >=20 > ] Michael Richardson, Sandelman Software Works | network > architect [ >=20 > ] mcr@sandelman.ca = http://www.sandelman.ca/ = = | ruby on rails > [ >=20 >=20 > -- > Michael Richardson >, Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=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. --Apple-Mail=_A848FCD0-E45D-4BCE-B424-852D2958D8E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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:
 
https://eprint.iacr.org/2017/349.pdf
 
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.

= --Apple-Mail=_A848FCD0-E45D-4BCE-B424-852D2958D8E5--