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

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

That is true, but here are my 2 cents.

I am open for a secure hash RFC with stable algorithm IDs that work both
for CBOR and ASN.1 encoded formats. I do believe that the IDs that are
currently defined in ASN.1 should suffice for 99%+ implementations.
We can get something for free by adopting standardized algorithm IDs.

For the emerging hash algorithms outside of what is standardized I think that
in the short term we could rely on the flexibility in the SUIT standard 
of allowing non-standard type IDs for work that goes besides standardized 
implementation. We can designate user-customizable negative numbers or 
reserved ranges for any hash algorithm that is not in the current approved 
secure cryptographic hash algorithms. 

The NIST/FIPS and CAVP (Cryptographic Algorithm Validation Program) is
the only option at this moment that gives a consistency in standardization
and validation. Selecting something beyond what is standardized and testable
moves the security aspects and the sensitivity into the hands of the designer, 
which is not something we should recommend for an out-of-the-box experience 
IMO.

Anyone wanting to use "something else" should be extremely aware of what they
are doing. Allowing a SUIT_Digest in a pure form in any portions of the 
standard doesn't accurately represent a "policy" of what should be allowed
or not. Making sure that only cryptographically sound algorithms are allowed 
limits the misuse. It doesn't remove the need for said "policy", but at least
it doesn't open up for a broad misuse in a generic reference-design 
implementation that is designed as an "allow all, support all".

It would be fairly simple to limit the hash-sizes in your implementation
just by stating that you will only accept e.g. SHA-2/SHA-3 of 256 bits or 
higher, but that is still just an implementer-decision. If you want to make a 
reference-design that "accepts everything" because you want it to be 
conformant with the standard, then the lack of a real "policy" concept gets 
trickier. People may make the wrong choices influencing their security.
I don't want to make this a viable problem, just because we made the 
use of a hash in the standard too open for interpretation.


2 cents mode off!

-Frank Audun.

> -----Original Message-----
> From: Waltermire, David A. (Fed) <[e-mail]>
> Sent: 12. april 2019 16:55
> 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
> 
> 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%2F
> > > > cs
> > > > 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