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

[Kvamtrø, Frank Audun <[e-mail]>]

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) <[e-mail]>
> Sent: 12. april 2019 16:06
> To: Kvamtrø, Frank Audun <[e-mail]>; Rønningstad, Øyvind
> <[e-mail]>; Brendan Moran <[e-mail]>;
> [e-mail]
> 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 <[e-mail]>
> > Sent: Friday, April 12, 2019 5:48 AM
> > To: Waltermire, David A. (Fed) <[e-mail]>;
> > Rønningstad, Øyvind <[e-mail]>; Brendan Moran
> > <[e-mail]>; [e-mail]
> > 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) <[e-mail]>
> > > Sent: 11. april 2019 17:49
> > > To: Rønningstad, Øyvind <[e-mail]>; Brendan
> > > Moran <[e-mail]>; [e-mail]
> > > Cc: Kvamtrø, Frank Audun <[e-mail]>
> > > Subject: RE: Introducing draft-moran-suit-manifest-04
> > >
> > > Some comments on Øyvind's comments below as a WG participant.
> > >
> > > > -----Original Message-----
> > > > From: Suit <[e-mail]> On Behalf Of Rønningstad,
> > > > Øyvind
> > > > Sent: Thursday, April 11, 2019 11:03 AM
> > > > To: Brendan Moran <[e-mail]>; [e-mail]
> > > > Cc: Kvamtrø, Frank Audun <[e-mail]>
> > > > 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