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

[Russ Housley <[e-mail]>]

Different security protocols use different techniques for naming algorithms.

X.509 Certificates and CMS use ASN.1 object identifiers.  COSE uses short text strings in text and integers on the wire.  TLS uses positive integer values.  All of these approaches can point to the same algorithm.

Since SUIT has selected the COSE format, that seems like a natural fit.  See https://www.iana.org/assignments/cose/cose.xhtml

Russ


> On Apr 12, 2019, at 10:36 AM, Kvamtrø, Frank Audun <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit