Re: [Suit] Introducing draft-moran-suit-manifest-04

Kvamtrø, Frank Audun <frank.kvamtro@nordicsemi.no> Fri, 12 April 2019 14:36 UTC

Return-Path: <frank.kvamtro@nordicsemi.no>
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 ABABA1207AE for <suit@ietfa.amsl.com>; Fri, 12 Apr 2019 07:36:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.onmicrosoft.com
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 NJM9WTPj3oJq for <suit@ietfa.amsl.com>; Fri, 12 Apr 2019 07:36:38 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0628.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::628]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6346312077D for <suit@ietf.org>; Fri, 12 Apr 2019 07:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.onmicrosoft.com; s=selector1-nordicsemi-no; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iwK9ZzO2aOs4oWrQOyVXaIPosLFu8ODVhBmTriKorkE=; b=hbakG3DJlhdVnPk9F2p8o6s7UEp+j6pN3FDKr0ZL+IgNLX+4zJy/IOL3bKkiftuYL6rn2TC/EqynAjYUP5WLQqk2/WHwn78qtEfZtdqEpnmIrO1XYOGA5HfB18pQK9snL6jfRNbmXQkCmJHJzS5s05y4wS3cj+SFqQfunGwVTG4=
Received: from AM6PR05MB6375.eurprd05.prod.outlook.com (20.179.5.214) by AM6PR05MB6136.eurprd05.prod.outlook.com (20.179.3.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.21; Fri, 12 Apr 2019 14:36:32 +0000
Received: from AM6PR05MB6375.eurprd05.prod.outlook.com ([fe80::98d9:6e05:1b71:2090]) by AM6PR05MB6375.eurprd05.prod.outlook.com ([fe80::98d9:6e05:1b71:2090%4]) with mapi id 15.20.1792.009; Fri, 12 Apr 2019 14:36:32 +0000
From: =?iso-8859-1?Q?Kvamtr=F8=2C_Frank_Audun?= <frank.kvamtro@nordicsemi.no>
To: "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>, =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= <Oyvind.Ronningstad@nordicsemi.no>, Brendan Moran <Brendan.Moran@arm.com>, "suit@ietf.org" <suit@ietf.org>
Thread-Topic: Introducing draft-moran-suit-manifest-04
Thread-Index: AQHU2L81dzELNCQKcEaCHfQ8cPehA6Y2x2+wgABw2OCAAAtb8IABCyQggABunaCAAAQtoA==
Date: Fri, 12 Apr 2019 14:36:31 +0000
Message-ID: <AM6PR05MB637519F9B91201C07B403EC8FC280@AM6PR05MB6375.eurprd05.prod.outlook.com>
References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> <HE1PR05MB32285B66AB7015921D83F852882F0@HE1PR05MB3228.eurprd05.prod.outlook.com> <HE1PR05MB32285EE3C40D73345D217935882F0@HE1PR05MB3228.eurprd05.prod.outlook.com> <SN6PR09MB3264D424FEEFFA6D998C6998F02F0@SN6PR09MB3264.namprd09.prod.outlook.com> <AM6PR05MB6375945D76E05467970B9358FC280@AM6PR05MB6375.eurprd05.prod.outlook.com> <SN6PR09MB3264B44FE3AD350746A8FA85F0280@SN6PR09MB3264.namprd09.prod.outlook.com>
In-Reply-To: <SN6PR09MB3264B44FE3AD350746A8FA85F0280@SN6PR09MB3264.namprd09.prod.outlook.com>
Accept-Language: nb-NO, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=frank.kvamtro@nordicsemi.no;
x-originating-ip: [194.19.86.146]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dbeb0a51-ad1e-488e-1e8c-08d6bf5441c1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:AM6PR05MB6136;
x-ms-traffictypediagnostic: AM6PR05MB6136:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <AM6PR05MB613662C7D1C8103B90DCF873FC280@AM6PR05MB6136.eurprd05.prod.outlook.com>
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(346002)(376002)(39850400004)(366004)(136003)(396003)(189003)(199004)(13464003)(476003)(26005)(11346002)(5660300002)(66066001)(9686003)(446003)(8936002)(6306002)(229853002)(99286004)(97736004)(7696005)(106356001)(3846002)(6506007)(105586002)(486006)(110136005)(966005)(478600001)(186003)(6246003)(81156014)(102836004)(6116002)(33656002)(53546011)(81166006)(76176011)(316002)(8676002)(71190400001)(53936002)(93886005)(45080400002)(68736007)(6436002)(74482002)(74316002)(71200400001)(45776006)(52536014)(14444005)(7736002)(2906002)(86362001)(55016002)(305945005)(14454004)(2501003)(66574012)(25786009)(256004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR05MB6136; H:AM6PR05MB6375.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nordicsemi.no does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: mbP+sCt3B4SkDmTKcTWJwBJ443r/qsmAhJU2km1jTgAslJEXOESQWAMPnJd1STXWa224kyinZExutalZbNklcv0KoCOI03SLXKZmYDIhKs3eqj+dt62b48IameQNoAJqckXSPcBXpnV6juARsP/pB7MjJD6ge93tY6dbq4AyYQlUIZkJpTBpCejl/OLUhFeqC97moAt327sho9Hep6NMlgYESUytucRH0fY9OlGVj1HRNcCFWUOoP1rSebn1HBPbXOAsbDbvXaRxEMUpu/cceDUw+GR4b8gUQKCYXdbkWf0ZNUPpHixJo3mIAXRl/e+WMFFY4ZHynGmbnV1duWQ2D7lxewLo5e0JbZKhsJzpWQwDM+oFsail0dRwhAT78ETqKzafCoEcDKqB/UMNMj64nLAd/kiugb4cscZnx4qqxWU=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nordicsemi.no
X-MS-Exchange-CrossTenant-Network-Message-Id: dbeb0a51-ad1e-488e-1e8c-08d6bf5441c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 14:36:31.9646 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 28e5afa2-bf6f-419a-8cf6-b31c6e9e5e8d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB6136
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/9oBQq-vUi20ePslA9kTCKp8XzLo>
Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
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, 12 Apr 2019 14:36:49 -0000

Total agreement on finding stable curated list, and hopefully this is a list
that can be one named "secure hashes" corresponding to active standards.

The Cryptographic Algorithm Object Registration from NIST seems to do exactly
that, with Object IDs that are stable. I know this is ASN.1 but it seems
easy to convert to pure integer Object IDs.

https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration#Hash

-Frank Audun

> -----Original Message-----
> From: Waltermire, David A. (Fed) <david.waltermire@nist.gov>
> Sent: 12. april 2019 16:06
> To: Kvamtrø, Frank Audun <frank.kvamtro@nordicsemi.no>no>; Rønningstad, Øyvind
> <Oyvind.Ronningstad@nordicsemi.no>no>; Brendan Moran <Brendan.Moran@arm.com>om>;
> suit@ietf.org
> Subject: RE: Introducing draft-moran-suit-manifest-04
> 
> Do we know anything about the permanence of and the process used to curate
> https://www.keylength.com/en/4/? The advantage of using IANA is that we can
> have confidence that the registry will exist and a known set of processes
> for managing it.
> 
> Alternately, could we write a small draft to add any missing hash algorithms
> (SHAKE128, SHAKE256, etc) to the Named Information Hash Algorithm Registry?
> This would allow the manifest to use the index values from the registry
> instead of defining a new enumeration.
> 
> Could we then say something in security considerations about the truncated
> hashes and their security properties referencing RFC6920?
> 
> Regards,
> Dave
> 
> > -----Original Message-----
> > From: Kvamtrø, Frank Audun <frank.kvamtro@nordicsemi.no>
> > Sent: Friday, April 12, 2019 5:48 AM
> > To: Waltermire, David A. (Fed) <david.waltermire@nist.gov>ov>;
> > Rønningstad, Øyvind <Oyvind.Ronningstad@nordicsemi.no>no>; Brendan Moran
> > <Brendan.Moran@arm.com>om>; suit@ietf.org
> > Subject: RE: Introducing draft-moran-suit-manifest-04
> >
> > Do note that there are no valid use-cases for heavily truncated hashes
> > in our information model. All hashes are exclusively used for security.
> > This makes me want to limit non-standard definitions that can be
> > misused and/or misunderstood.
> >
> > When the RFC talks about the truncated hash they mention security
> > specifically:
> >
> >   "... Therefore, we use different hash algorithm strings in these cases,
> >   such as sha-256-32 for a 32-bit truncation of a sha-256 output.  A 32-
> bit
> >   truncated hash is essentially useless for security in almost all cases
> but
> >   might be useful for naming."
> >
> >
> > Where we source the list to use in manifest of the hash types is the
> > big question...
> >
> > I often times go to the following web-page to find the latest on
> > recommended hashes etc:
> > https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > keylength.com%2Fen%2F4%2F&amp;data=02%7C01%7Cdavid.waltermire%
> > 40nist.gov%7C4a660097d25a453e13e208d6bf2c06ff%7C2ab5d82fd8fa4797a
> > 93e054655c61dec%7C1%7C0%7C636906593156044698&amp;sdata=PGgJTO
> > l48DmN9onJtbkogKWAGB%2FJ9omRAeZDX2OOobA%3D&amp;reserved=0
> >
> > This page lists the approved hashes as sourced from NIST specs:
> >
> > From FIPS 180-4:
> > SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256
> >
> > (Where SHA-384 is essentially SHA-512/384)
> >
> > From FIPS 202:
> > SHA3-224,SHA3-256, SHA3-384,SHA3-512, SHAKE128, SHAKE256.
> >
> >
> > I would like to reference the Cryptographic Algorithm Object
> > Registration from NIST for the ASN.1 encoding of approved cryptographic
> algorithms.
> >
> > https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc
> > .n
> > ist.rip%2Fgroups%2FST%2Fcrypto_apps_infra%2Fcsor%2Falgorithms.html&a
> > mp;data=02%7C01%7Cdavid.waltermire%40nist.gov%7C4a660097d25a453e
> > 13e208d6bf2c06ff%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C
> > 636906593156044698&amp;sdata=VPHEv850i7bKsIbUsdx7Pc8o8j7xnTPDKsv
> > R%2B4qeEaE%3D&amp;reserved=0
> >
> > SHA-1 (Externally assigned)
> > SHA-2 family
> > id-sha256 OBJECT IDENTIFIER ::= { hashAlgs 1 }
> > id-sha384 OBJECT IDENTIFIER ::= { hashAlgs 2 }
> > id-sha512 OBJECT IDENTIFIER ::= { hashAlgs 3 }
> > id-sha224 OBJECT IDENTIFIER ::= { hashAlgs 4 }
> > id-sha512-224 OBJECT IDENTIFIER ::= { hashAlgs 5 }
> > id-sha512-256 OBJECT IDENTIFIER ::= { hashAlgs 6 }
> >
> > SHA-3 family
> > id-sha3-224 OBJECT IDENTIFIER ::= { hashAlgs 7 }
> > id-sha3-256 OBJECT IDENTIFIER ::= { hashAlgs 8 }
> > id-sha3-384 OBJECT IDENTIFIER ::= { hashAlgs 9 }
> > id-sha3-512 OBJECT IDENTIFIER ::= { hashAlgs 10 }
> > id-shake128 OBJECT IDENTIFIER ::= { hashAlgs 11 }
> > id-shake256 OBJECT IDENTIFIER ::= { hashAlgs 12 } id-shake128-len
> > OBJECT IDENTIFIER ::= { hashAlgs 17 } id-shake256-len OBJECT
> > IDENTIFIER ::= { hashAlgs 18 }
> >
> >
> > Using this should provide the complete list of recommended and
> > approved hashes, formatted as the IETF SUIT spec, semi-conformant to
> > the "Named Information Hash Algorithm Registry":
> >
> > algorithm-id-sha-256        = 1
> > algorithm-id-sha-384        = 2
> > algorithm-id-sha-512        = 3
> > algorithm-id-sha-224        = 4
> > algorithm-id-sha-512-224    = 5
> > algorithm-id-sha-512-256    = 6
> > algorithm-id-sha3-224       = 7
> > algorithm-id-sha3-256       = 8
> > algorithm-id-sha3-384       = 9
> > algorithm-id-sha3-512       = 10
> >
> > digest-algorithm-ids /= algorithm-id-sha-256 digest-algorithm-ids /=
> > algorithm-id-sha-384 digest-algorithm-ids /= algorithm-id-sha-512
> > digest-algorithm-ids /= algorithm-id-sha-224 digest-algorithm-ids /=
> > algorithm-id-sha-512-224 digest-algorithm-ids /=
> > algorithm-id-sha-512-256 digest-algorithm-ids /= algorithm-id-sha3-224
> > digest-algorithm-ids /= algorithm-id-sha3-256 digest-algorithm-ids /=
> > algorithm-id-sha3-384 digest-algorithm-ids /= algorithm-id-sha3-512
> >
> > Note that SHA-1 is removed from this list due to being a "legacy" type
> > hash (known to be broken). SHAKE is also removed as it isn't directly
> > approved due to the complexity of use.
> >
> > Note that I've added a dash between "sha" and "256" according to spec
> > and consistent with "Named Information Hash Algorithm Registry".
> >
> > Additional hashes may also be easy to add, like KECCAC.
> >
> > I recommend reusing the algorithm IDs from ASN.1 in lack of any
> > meaningful listing, elsewhere.
> >
> > -Frank Audun
> >
> > > -----Original Message-----
> > > From: Waltermire, David A. (Fed) <david.waltermire@nist.gov>
> > > Sent: 11. april 2019 17:49
> > > To: Rønningstad, Øyvind <Oyvind.Ronningstad@nordicsemi.no>no>; Brendan
> > > Moran <Brendan.Moran@arm.com>om>; suit@ietf.org
> > > Cc: Kvamtrø, Frank Audun <frank.kvamtro@nordicsemi.no>
> > > Subject: RE: Introducing draft-moran-suit-manifest-04
> > >
> > > Some comments on Øyvind's comments below as a WG participant.
> > >
> > > > -----Original Message-----
> > > > From: Suit <suit-bounces@ietf.org> On Behalf Of Rønningstad,
> > > > Øyvind
> > > > Sent: Thursday, April 11, 2019 11:03 AM
> > > > To: Brendan Moran <Brendan.Moran@arm.com>om>; suit@ietf.org
> > > > Cc: Kvamtrø, Frank Audun <frank.kvamtro@nordicsemi.no>
> > > > Subject: [Suit] FW: Introducing draft-moran-suit-manifest-04
> > > >
> > > > I did a full pass through the document today, and wrote down
> > > > (quite a
> > > > few) comments, see below. I think this document is very exciting!
> > > >
> > > > - Øyvind
> > > >
> > > >
> > > > The digest-algorithm-ids list is missing the following SHA-2
> > > > family
> > > functions:
> > > >  - SHA224
> > > >  - SHA512/224
> > > >  - SHA512/256
> > > > Also, the functions that are truncated to 128 and fewer bits will
> > > > not be secure against brute-force attacks, so I question their
> > > > inclusion
> > here.
> > >
> > > RFC 6920, which this draft references, defines the IANA "Named
> > > Information Hash Algorithm Registry". It would be good if this draft
> > > directly references the "Named Information Hash Algorithm Registry"
> > > directly to provide for future agility as new algorithms are added
> > > and use of specific algorithms fall out of practice. The "status"
> > > field of the registry provides guidance for the later. Algorithm
> > > agility should also be discussed in the security considerations.
> > >
> > > It would also be useful to allow non-enumerated integer values to be
> > > used in the format to ensure that new entries added to the "Named
> > > Information Hash Algorithm Registry" are also allowed to be used in
> > > the
> > format.
> > >
> > > Regards,
> > > Dave