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

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

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 <[e-mail]>
> Sent: Friday, April 12, 2019 10:37 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
> 
> 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%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) <[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