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

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

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://www.keylength.com/en/4/

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://csrc.nist.rip/groups/ST/crypto_apps_infra/csor/algorithms.html

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