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

Tony Putman <Tony.Putman@dyson.com> Fri, 22 June 2018 08:13 UTC

Return-Path: <prvs=704362c8c=Tony.Putman@dyson.com>
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 87070130DFC for <suit@ietfa.amsl.com>; Fri, 22 Jun 2018 01:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Level:
X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Z7IQWcoIC8aY for <suit@ietfa.amsl.com>; Fri, 22 Jun 2018 01:13:29 -0700 (PDT)
Received: from esa1.dyson.c3s2.iphmx.com (esa1.dyson.c3s2.iphmx.com [68.232.133.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C276D130DC6 for <suit@ietf.org>; Fri, 22 Jun 2018 01:13:28 -0700 (PDT)
X-IronPort-SPF: SKIP
X-IronPort-AV: E=McAfee;i="5900,7806,8931"; a="40321826"
X-IronPort-AV: E=Sophos; i="5.51,256,1526338800"; d="scan'208,217"; a="40321826"
Received: from unknown (HELO uk-dlp-smtp-02.dyson.global.corp) ([62.189.202.16]) by esa1.dyson.c3s2.iphmx.com with ESMTP; 22 Jun 2018 09:24:39 +0100
Received: from uk-dlp-smtp-02.dyson.global.corp (uk-dlp-smtp-02.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 6E4F594702; Fri, 22 Jun 2018 06:52:12 +0000 (GMT)
Received: from UK-MAL-CAS-01.dyson.global.corp (unknown [10.1.108.2]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 4A22294711; Fri, 22 Jun 2018 06:52:12 +0000 (GMT)
Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-01.dyson.global.corp ([fe80::e820:2e99:cbf:405b%16]) with mapi id 14.03.0319.002; Fri, 22 Jun 2018 09:13:22 +0100
From: Tony Putman <Tony.Putman@dyson.com>
To: Russ Housley <housley@vigilsec.com>
CC: suit <suit@ietf.org>, Dave Thaler <dthaler@microsoft.com>, Brendan Moran <Brendan.Moran@arm.com>
Thread-Topic: [Suit] draft-housley-suit-cose-hash-sig
Thread-Index: AQHUA0IpmCMrPXwNBEGZJN1O4yNrXaReex0AgAxR0ACAAAjwgIAABWoAgAABigCAADxBAIAA4PKg
Date: Fri, 22 Jun 2018 08:13:22 +0000
Message-ID: <140080C241BAA1419B58F093108F9EDC1E0D1690@UK-MAL-MBOX-01.dyson.global.corp>
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> <DM5PR2101MB0805F9D2D2372C4AEE2C7E5BA3760@DM5PR2101MB0805.namprd21.prod.outlook.com> <AD7239DB-B6C4-4D3A-8DDE-ACA9CB430263@vigilsec.com>
In-Reply-To: <AD7239DB-B6C4-4D3A-8DDE-ACA9CB430263@vigilsec.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.108.27]
Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC1E0D1690UKMALMBOX01dyso_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/Ej5y5Mfu2DygBP28QPfbdJuv_94>
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 <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jun 2018 08:13:33 -0000

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<mailto: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<mailto:suit-bounces@ietf.org>> On Behalf Of Brendan Moran
Sent: Thursday, June 21, 2018 9:03 AM
To: Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Cc: suit <suit@ietf.org<mailto: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’t pretend to understand all COSE use cases.

Thanks,
Brendan



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

Russ




On Jun 21, 2018, at 11:11 AM, Brendan Moran <Brendan.Moran@arm.com<mailto: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://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-irtf-cfrg-xmss-hash-based-signatures-12<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>

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<mailto:ietf@augustcellars.com>> wrote:





-----Original Message-----
From: Suit <suit-bounces@ietf.org<mailto:suit-bounces@ietf.org>> On Behalf Of Michael Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <suit@ietf.org<mailto: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<mailto:mcr@sandelman.ca>  http://www.sandelman.ca/<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>        |   ruby on rails
[



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




_______________________________________________
Suit mailing list
Suit@ietf.org<mailto:Suit@ietf.org>
https://www.ietf.org/mailman/listinfo/suit<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>

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.