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

"Waltermire, David A. (Fed)" <david.waltermire@nist.gov> Fri, 12 April 2019 14:55 UTC

Return-Path: <david.waltermire@nist.gov>
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 A55161207DF for <suit@ietfa.amsl.com>; Fri, 12 Apr 2019 07:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=nist.gov
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 BVhLa-DIE7Tq for <suit@ietfa.amsl.com>; Fri, 12 Apr 2019 07:55:30 -0700 (PDT)
Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840118.outbound.protection.outlook.com [40.107.84.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA451207DE for <suit@ietf.org>; Fri, 12 Apr 2019 07:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N1nsZ4U7o+n7QKzNTSa/TDaSPm7KQ5ni1JASd8SeFo8=; b=1VHVDxTM1kgeNO5pbTqznego5tcCMJ8eB+sV5iruMSYI2eCpttbu/P8o9RVuBRNkDRGu1KYVjLnjXs9XNOweaR315BBbK+tV3ZZMFNpqGzDxBb/5htlEtuz2bqpopXAUYCJbIN1+ixfoul85hc9sefcHs1mmBHYSh9gvj+8vIp8=
Received: from SN6PR09MB3264.namprd09.prod.outlook.com (20.177.251.21) by SN6PR09MB3263.namprd09.prod.outlook.com (20.177.251.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Fri, 12 Apr 2019 14:55:27 +0000
Received: from SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::d40a:9312:f1f:9048]) by SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::d40a:9312:f1f:9048%5]) with mapi id 15.20.1792.016; Fri, 12 Apr 2019 14:55:27 +0000
From: "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>
To: =?iso-8859-1?Q?Kvamtr=F8=2C_Frank_Audun?= <frank.kvamtro@nordicsemi.no>, =?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+wgABw2OCAAAtb8IABCyQggABunaCAAAQtoIAACtpA
Date: Fri, 12 Apr 2019 14:55:26 +0000
Message-ID: <SN6PR09MB3264B9698A249490E05F66E1F0280@SN6PR09MB3264.namprd09.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> <AM6PR05MB637519F9B91201C07B403EC8FC280@AM6PR05MB6375.eurprd05.prod.outlook.com>
In-Reply-To: <AM6PR05MB637519F9B91201C07B403EC8FC280@AM6PR05MB6375.eurprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov;
x-originating-ip: [129.6.225.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 774704ed-b3d1-4a71-1a99-08d6bf56e642
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:SN6PR09MB3263;
x-ms-traffictypediagnostic: SN6PR09MB3263:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <SN6PR09MB3263672FB8EC2C57267E7AFDF0280@SN6PR09MB3263.namprd09.prod.outlook.com>
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(366004)(136003)(39860400002)(13464003)(189003)(199004)(68736007)(71200400001)(102836004)(81166006)(74316002)(81156014)(66574012)(966005)(7736002)(66066001)(71190400001)(305945005)(14454004)(6116002)(3846002)(33656002)(2906002)(52536014)(45080400002)(6436002)(478600001)(5660300002)(6246003)(476003)(110136005)(486006)(53936002)(446003)(256004)(316002)(97736004)(99286004)(11346002)(7696005)(229853002)(2501003)(9686003)(76176011)(53546011)(8676002)(55016002)(6306002)(186003)(6506007)(26005)(105586002)(106356001)(86362001)(8936002)(25786009)(93886005)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR09MB3263; H:SN6PR09MB3264.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: MUEkEoFQGem5Xo0tEC+6pJSVlo0Iwrm+SewJmep/kXPL/svK3dWK78szuxdfbPkh8XFHY/rEfIWgl31eXtD8sloGpb1y0M9x1U3Yxr88XkeuYWYG+nm1VgI93afaB9HabfIWNsF23CGGASazNcuGc2njRHid52DemGEghR1HWECtzBp+M5PSeaYMn56WDqnnS3IpyOnmZesN7JRA82rIJjvCABzMkNkPcNsfBJcd0CJMIAns1HFfxffmJyJpfWk8DF2qlAdIDq0CuGNFGYgTtuZRXoz8dNO46F5VpIL2pOjsIS4WsVrgGP1mELhoKtwVrMM/ov9VHFTph0kUgW5rxq/V+YcL7yHNiGyE8t2+fkJPEOAlMl7fWq38n/xx2E0ZRg0P6NdvT3p4pTImS0yopjgw7K9el0DJLcqrLMbfulo=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 774704ed-b3d1-4a71-1a99-08d6bf56e642
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 14:55:26.8907 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR09MB3263
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/0g_b94t5p_3cnCsAQB4R8fcGMIE>
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:55:34 -0000

True. My concern is that the NIST list contains only NIST approved algorithms. 

The IETF may want to include a larger scope of hash algorithms that go beyond those supported by NIST. Keeping this list in IANA provides for that larger scope.

Regards,
Dave



> -----Original Message-----
> From: Kvamtrø, Frank Audun <frank.kvamtro@nordicsemi.no>
> Sent: Friday, April 12, 2019 10:37 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
> 
> 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%2Fcs
> > > rc
> > > .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