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

Tony Putman <Tony.Putman@dyson.com> Fri, 22 June 2018 16:47 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 85D3A130EB0 for <suit@ietfa.amsl.com>; Fri, 22 Jun 2018 09:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 6XmUG9aBLgRY for <suit@ietfa.amsl.com>; Fri, 22 Jun 2018 09:47:07 -0700 (PDT)
Received: from esa2.dyson.c3s2.iphmx.com (esa2.dyson.c3s2.iphmx.com [68.232.133.94]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFBA130EAC for <suit@ietf.org>; Fri, 22 Jun 2018 09:47:06 -0700 (PDT)
X-IronPort-SPF: SKIP
X-IronPort-AV: E=McAfee;i="5900,7806,8932"; a="35145484"
X-IronPort-AV: E=Sophos; i="5.51,257,1526338800"; d="scan'208,217"; a="35145484"
Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa2.dyson.c3s2.iphmx.com with ESMTP; 22 Jun 2018 17:57:57 +0100
Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id 1853BFA10; Fri, 22 Jun 2018 14:55:02 +0000 (GMT)
Received: from UK-MAL-CAS-01.dyson.global.corp (unknown [10.1.108.2]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id F3884FA02; Fri, 22 Jun 2018 14:55:01 +0000 (GMT)
Received: from UK-MAL-CAS-04.dyson.global.corp (10.1.108.112) by UK-MAL-CAS-01.dyson.global.corp (10.1.108.2) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 22 Jun 2018 17:47:03 +0100
Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-04.dyson.global.corp ([10.1.108.112]) with mapi id 14.03.0319.002; Fri, 22 Jun 2018 17:47:03 +0100
From: Tony Putman <Tony.Putman@dyson.com>
To: Russ Housley <housley@vigilsec.com>
CC: suit <suit@ietf.org>
Thread-Topic: [Suit] draft-housley-suit-cose-hash-sig
Thread-Index: AQHUA0IpmCMrPXwNBEGZJN1O4yNrXaReex0AgAxR0ACAAAjwgIAABWoAgAABigCAADxBAIAA4PKggAACaICAAAaUAIAAhXjQ
Date: Fri, 22 Jun 2018 16:47:03 +0000
Message-ID: <140080C241BAA1419B58F093108F9EDC1E0D18AA@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> <140080C241BAA1419B58F093108F9EDC1E0D1690@UK-MAL-MBOX-01.dyson.global.corp> <18F16995-D6BF-4C68-9E93-B1CF93D4369D@vigilsec.com> <B5A03C05-5058-4BFB-90F0-752DFD78661A@vigilsec.com>
In-Reply-To: <B5A03C05-5058-4BFB-90F0-752DFD78661A@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_140080C241BAA1419B58F093108F9EDC1E0D18AAUKMALMBOX01dyso_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/KX5VgQvsDi3iTqcFYDu_yUTabcI>
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 16:47:10 -0000

Hi Russ,

Some further comments on your draft suit-cose-hash-sig:

In a number of places, starting in section 3, you limit this specification
to using SHA-256. As far as I can see, if a new RFC were issued updating
[HASHSIG} and using a different hash function, this specification would
not change due to the self-describing nature of the signature. So while
the restriction applies to [HASHSIG}, which is defining actual signatures,
I believe it does not apply to this draft, which is defining a way to
transport signatures.

Section 3.1: "Each signed public key is represented by the hash value at
the root of the tree": it also contains information about the tree
structure (type and otstype) and the identity I; but perhaps this detail
is not needed.

End of section 3.1: I find the text "lms_signature_on_public_key[0]"
(and so on) misleading because the signature is actually on public_key[1].
I feel it would be better to be a bit more verbose, and define:
  signature[k-1] = lms_signature_on_public_key_k_using_private_key[k-1]
  signed_public_key[k] = signature[k-1] || public_key[k]
Then the overall tree is just
  u32str(Nspk) ||
  signed_public_key[1] ||
  signed_public_key[2] ||
     ...
  signed_public_key[Nspk-1] ||
  signed_public_key[Nspk] ||
  lms_signature_on_message_using_private_key[Nspk]

Section 3.2, third paragraph: I suggest putting the elements in the same
order that they appear in the signature, namely:
  "An LMS signature consists of four elements: the number of the leaf
   associated with the LM-OTS signature, an LM-OTS signature as described
   in Section 3.3, a typecode indicating the particular LMS algorithm,
   and an array of values that is associated with the path through the
   tree from the leaf associated with the LM-OTS signature to the root."
It is probably worth noting here that the LM-OTS signature starts with
an ots-typecode, so that the signature can be easily parsed.

Section 3.3, last line: I suggest replacing the first element with
u32str(otstype) for clarity. It should be clear from context, but I think
it's worth emphasising.

Section 4, second paragraph: "The first four bytes of each LMS signature
value contains type code" is not correct. I suggest being less specific
and say something like "the LMS signature value is self-describing", as
parsing is a little more difficult to explain. Alternatively, reverse the
order of describing the parts, to that the self-parsing of the OTS
signature has already been explained before coming to the LMS signature.

Section 4: There is no mention of which kid to use. This may be a matter
of convention between sender and receiver, but if public keys are used
as trust anchors then the identity I of the public key could be sent in
the kid field. I think this should be mentioned at least as a MAY, to
facilitate interoperability.

Section 5.1, last paragraph: The generation of signatures also relies on
random numbers. Their generation is much less sensitive than the generation
of private keys, so don't lump them together in the same paragraph, but
it is worth a mention. As an aside, is there any investigation into a
deterministic signature, e.g. by setting C to a hash of all the private
keys?

Section 6: Some more idle speculation on my part. In software update,
the signed bundle *should* have a unique version number. If there were
a way to map version number to LMS node, this would provide a different
way to ensure that the same key was never reused. But I agree that such
a discussion doesn't belong in this document.

Section 7.1/7.2: Please update the "Description" to be more specific,
such as:
  "Description:  Hash-based digital signatures using HSS/LMS" and
  "Description: Public key of HSS/LMS hash-based digital signature"

Best regards,
Tony


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.