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

["Waltermire, David A. (Fed)" <[e-mail]>]

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