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 D4F47130E0F for ; Thu, 21 Jun 2018 13:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 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, SPF_PASS=-0.001, 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 Lm7sZIh8zFXe for ; Thu, 21 Jun 2018 13:14:59 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A133130E14 for ; Thu, 21 Jun 2018 13:14:58 -0700 (PDT) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 21 Jun 2018 13:11:51 -0700 From: Jim Schaad To: 'Russ Housley' , 'Dave Thaler' , 'Brendan Moran' CC: 'suit' 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> In-Reply-To: Date: Thu, 21 Jun 2018 13:14:47 -0700 Message-ID: <014901d4099c$82be6150$883b23f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014A_01D40961.D6688A00" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHwZWPvfC0oH/KJpPKzh2KFlMHiSQFvEQHtAbrOmkYA7bECGAHMf9bXAeyn/S8A68Uj4qPsiX3w Content-Language: en-us X-Originating-IP: [50.252.25.182] 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 20:15:03 -0000 ------=_NextPart_000_014A_01D40961.D6688A00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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. =20 Doing this separately when we know they are going to be used (or = potentially used) makes more sense to me. =20 Jim =20 =20 From: Suit On Behalf Of Russ Housley Sent: Thursday, June 21, 2018 12:44 PM 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 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 < 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 =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 On 21 Jun 2018, at 16:43, Russ Housley < = housley@vigilsec.com> 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 On Jun 21, 2018, at 11:11 AM, Brendan Moran < = Brendan.Moran@arm.com> 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 On 13 Jun 2018, at 20:03, Jim Schaad < = ietf@augustcellars.com> wrote: =20 -----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 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 [ ] 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 =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 ------=_NextPart_000_014A_01D40961.D6688A00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I have not = looked in detail at the XMSS signature structure =C2=A0and key structure = and would want to do so before making any type of definitive = statement.=C2=A0 However different drafts defining the different = signature structures is what I would generally expect unless there is a = huge overlap between them.=C2=A0 I would guess that the key structures = are also different and thus would probably need to be identified = differently.=C2=A0 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 = <suit-bounces@ietf.org> On Behalf Of Russ = Housley
Sent: Thursday, June 21, 2018 12:44 PM
To: = Dave Thaler <dthaler@microsoft.com>; Brendan Moran = <Brendan.Moran@arm.com>
Cc: suit = <suit@ietf.org>
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:<= span class=3Dapple-converted-space> 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:

=

 

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:

 




=

-----Origina= l 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
           = ;     creating a hash-based = signature.

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

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

somehow
<= br>

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

private
<= br>

(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




--
] =             &= nbsp; Never tell me the odds! =             &= nbsp;   | ipv6 mesh

networks = [


] =   Michael Richardson, Sandelman Software Works =        | network

architect =  [


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

[


--
Mi= chael 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<= /a>

 

------=_NextPart_000_014A_01D40961.D6688A00--