Subject: [Suit] FW: Introducing draft-moran-suit-manifest-04

From: Rønningstad, Øyvind <[email-masked]>
Date: Thu, 11 Apr 2019 15:02:57 +0000

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.

The requirement that all manifests must have a sequence number higher than their dependencies might be inconvenient when dependencies are validated by version ranges, since a dependency might be updated to something that is created after the root manifest, but still fulfills the check. Comparing sequence number dependency<->dependent might be superfluous, since the dependency is already referenced quite specifically in other ways. Alternatively, the requirement can be valid only up to and including installation.
Also, the text should probably mention that if a manifest is replaced by an update, the new manifest must have a higher sequence number.

What directives/conditions can apply to components in suit-dependency-components? I don't quite understand the purpose of the suit-dependency-components list.

I read it many times now, but I don't really understand the last paragraph of "8.4.  SUIT_Component". Can you elaborate on the assumptions? How are the values dependent on installation offset? Who updates the parameters to match what? What does "defining a component" mean?

I might have missed something, but can you elaborate on how scoping of parameters work, specifically when are they unset? For example Encryption Info, does it become unset after being used once? Which parameters are inherited into a Run_Sequence or Process_Dependency? Does a Set_Component_Index/Set_Manifest_Index effectively unset all parameters that have scope "Component"/"Dependency". How does scoping affect parallell processing (how to keep track of the value of a parameter for a given Directive/Conditition if they are executed out of order)?	

SUIT_Unpack_Algorithm_Delta should be split into individual IDs for algorithms like SUIT_Unpack_Algorithm_VCDIFF.

I think there's a quirk with the versions where comparisons can be subverted. If you have a dependency on version 1.x of something, it's hard (impossible in the general sense) to express those bounds with the greater/lesser comparisons. This is because there is no well-defined highest or lowest version with a given prefix such as "1." (unless the version list has bounded length).  If you have a bound on the length of the version list, you could express the upper bound e.g. as "Lesser or equal than 1.INTMAX.INTMAX..." etc. which isn't very pretty. Can we find some better way? I'm assuming 1.1 is equivalent (equal) to 1.1.0 etc.

If SUIT_Directive_Set_Component_Index is set to ALL components, is the order in which it applies to the components well-defined? Same question for SUIT_Directive_Set_Manifest_Index. 

Can you give an example of providing an argument to SUIT_Directive_Fetch?

The CDDL for Condition, Directive and Parameters should have the name as part of the CDDL (i.e. as a label/type, not a comment) to make it more amenable to machine parsing.

*The rest is nitpicking*

The SUIT_Manifest CDDL references Digest instead of SUIT_Digest.

Should suit-install be MANDATORY if suit-payload-fetch is present?

I suggest being more specific about suit-validate. Something to the effect of: "suit-validate is a SUIT_Command_Sequence to execute in order to validate that the result of applying the update (i.e. the state of the device after suit-install) is correct."

When forwarding a dependency to a component that is capable of parsing its own manifests, the dependency manifest might not be SUIT-formatted, so it should not need to be interpreted. This could be elaborated on in the text.

This sentence should probably be fixed (typo etc.): "It consists of three elemnts: the component identifier that represents a component that will be affected by this manifest."

Can a SUIT_Component_Reference refer to a component in a dependency of a dependency?

For readability, I suggest placing the "name" column (of the manifest parameters table) further to the left.

Can you elaborate on the "Skip" flag for parameters? Even just mentioning that it is TBD.

This could be more specific: "This index is a numeric index into the component ID tables defined at the beginning of the document."

SUIT_Directive_Set_Parameter_State_Append is not mentioned in the table.

Should "dependent-components" be "dependency-components" instead?

For the sake of completeness: In "Access Control Lists" I envision another situation, where ACL is implemented as a function that e.g. takes the Component ID and returns the identities that can manipulate it. This is for when Component IDs can alias each other, or the component ID contains a flash address, so it doesn't make sense to store every conceivable component ID in a list.

The names in the example in "Creating conditional sequences" don't look right, are they outdated?

An example with dependencies would of course be useful.

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Brendan Moran
Sent: Tuesday, March 12, 2019 11:35
To: [email-masked]
Subject: [Suit] Introducing draft-moran-suit-manifest-04

draft-moran-suit-manifest-04 has now been published.

https://tools.ietf.org/html/draft-moran-suit-manifest-04

This draft is the result of combining the information model in draft-moran-suit-behavioural-manifests-00 (the 01 version fixes example formatting only) with that in draft-ietf-suit-information-model, then serialising the result in CBOR. This is a significant departure from previous drafts. It attempts to preserve flexibility, fully define the behaviour of recipient, simplify the manifest structure, reduce code-size of the recipient, and reduce the size of the manifest. This ambitious set of goals required a significant change in approach as compared to draft-moran-suit-manifest-03 and before. In order to outline the approach clearly, we have separately published draft-moran-suit-behavioural-manifests-00. draft-moran-suit-manifest-04 focuses more on the serialisation of the manifest.

I look forward to discussing this draft in more detail.

Best Regards,
Brendan
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Thu, 11 Apr 2019 15:48:50 +0000

Some comments on Øyvind's comments below as a WG participant.

> From: Suit <[email-masked]> On Behalf Of Rønningstad, Øyvind
> Sent: Thursday, April 11, 2019 11:03 AM
> To: Brendan Moran <[email-masked]>; [email-masked]
> Cc: Kvamtrø, Frank Audun <[email-masked]>
> 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
> 
> 
> 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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Apr 2019 13:10:42 -0400

{catching up on the thread, having read the documents}

David Brown <[email-masked]> wrote:
    > - The download part of an upgrade happens while the application is
    > running, and this code is contained within the code currently
    > running in the primary image.  It downloads the upgrade into the
    > "secondary" slot.  This new code cannot execute at this address,
    > but is placed here as the image is downloaded.  The assumption is
    > that their isn't sufficient RAM to hold the entire image, and that
    > a download may be interrupted.

Are there systems that you target where the minimal MMU could actually remap
things?

    > - Using the scratch area exchange the images in the primary and
    > secondary slot
...

    > This is designed in such a way that it can resume after any
    > untimely interruption.

I guess the scratch area is not big enough for the entire image, but if there
is an interruption, then the bootloader simply continues to do the swap?

    > Within either the primary or secondary slot, the image has a format
    > similar to:

    > +------------+
    > | Header     |
    > +------------+
    > | Executable |
    > +------------+
    > | Manifest   |
    > +------------+

    > there is no real separate place to store the manifest.  This does mean
    > that during an upgrade the manifest for both the old and the new image
    > are present in flash.

It seems that maybe there is an opportunity here, but I don't know what it is yet.

    > I'm curious what thoughts people have on how to apply the draft 4
    > manifest to the above scenario.  Operations such as "load" aren't
    > really meaningful, but apply-image would certainly make sense.

    > However, the installation of a new image is partially initiated by a
    > different piece of code than the bootloader which is responsible for
    > actually installing the image.  This state has to be managed carefully
    > in a way that works with NOR flash, and therefore will probably live
    > outside of the manifest.

I see your point.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Apr 2019 13:17:35 -0400

David Brown <[email-masked]> wrote:
    >> Reboot resilience for “swap” is probably outside the scope of this draft.
    >> Adding a condition to check the success marker might be useful.

    > I'm not sure it really even makes sense to describe the reboot
    > resilience in the manifest.  At least for swap, it is a large number
    > of steps that have to be done carefully, along with a lot of extra
    > state that is written every step.  I would think this intermediate
    > state is beyond the scape of the manifest.

    > For those interested, I've thrown together a bit of an amination
    > describing how the swap operation works in MCUboot, including at least
    > part of its state.

    > https://www.youtube.com/watch?v=TvXjw2l0Cd0

    > I'm not actually sure it is even going to make very much sense for
    > MCUboot to follow steps in the manifest, rather than just verifying
    > that they are present.  The steps make sense for the download
    > application.

Very nice animation.
It really seems like the swap operation does by MCUboot ought to be below the
level of the manifest instructions.

    > One difficulty I see following steps in the manifest is that the code
    > currently maintains state out-of-band from the manifest.  The current
    > state is:

That suggests to me that maybe we need to make the state explicit in the
information model associated with the manifest.

    > Any thoughts on what is appropriate to even represent in the manifest?
    > The two instructions that the bootloader would follow would be "swap"
    > or "apply" (depending on configuration), and "run".  Right now, we
    > distinguish swap vs copy by whether the new image contains the "image
    > ok" marker, but having two instructions could distinguish this as
    > well.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Kvamtrø, Frank Audun <[email-masked]>
Date: Fri, 12 Apr 2019 09:48:20 +0000

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

> From: Waltermire, David A. (Fed) <[email-masked]>
> Sent: 11. april 2019 17:49
> To: Rønningstad, Øyvind <[email-masked]>; Brendan Moran
> <[email-masked]>; [email-masked]
> Subject: RE: 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
> >
> >
> > 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

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 12 Apr 2019 14:06:13 +0000

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

> From: Kvamtrø, Frank Audun <[email-masked]>
> Sent: Friday, April 12, 2019 5:48 AM
> To: Waltermire, David A. (Fed) <[email-masked]>; Rønningstad,
> Øyvind <[email-masked]>; Brendan Moran
> Do note that there are no valid use-cases for heavily truncated hashes in our
> information model. All hashes are exclusively used for security.
> 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
> 
> 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
> 
> id-shake256 OBJECT IDENTIFIER ::= { hashAlgs 12 } id-shake128-len OBJECT
> IDENTIFIER ::= { hashAlgs 17 } id-shake256-len OBJECT IDENTIFIER ::= {
> hashAlgs 18 }
> 
> 
> 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
> 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 I've added a dash between "sha" and "256" according to spec and
> consistent with "Named Information Hash Algorithm Registry".
> 
> I recommend reusing the algorithm IDs from ASN.1 in lack of any meaningful
> listing, elsewhere.
> 
> -Frank Audun
> 
> > To: Rønningstad, Øyvind <[email-masked]>; Brendan
> > Moran <[email-masked]>; [email-masked]
> > > 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

---

From: Kvamtrø, Frank Audun <[email-masked]>
Date: Fri, 12 Apr 2019 14:36:31 +0000

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

> Sent: 12. april 2019 16:06
> To: Kvamtrø, Frank Audun <[email-masked]>; Rønningstad, Øyvind
> <[email-masked]>; Brendan Moran <[email-masked]>;
> [email-masked]
> 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
> 
> > To: Waltermire, David A. (Fed) <[email-masked]>;
> > Rønningstad, Øyvind <[email-masked]>; Brendan Moran
> > This makes me want to limit non-standard definitions that can be
> > misused and/or misunderstood.
> >
> > Where we source the list to use in manifest of the hash types is the
> > big question...
> >
> > I would like to reference the Cryptographic Algorithm Object
> > Registration from NIST for the ASN.1 encoding of approved cryptographic
> algorithms.
> >
> > 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
> > 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 /=
> > 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.
> >
> > > > The digest-algorithm-ids list is missing the following SHA-2
> > > > family
> > > functions:
> > > >  - SHA224
> > > >  - SHA512/224
> > > >  - SHA512/256
> > > 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.
> > >

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 12 Apr 2019 14:55:26 +0000

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

> Sent: Friday, April 12, 2019 10:37 AM
> 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
> > To: Kvamtrø, Frank Audun <[email-masked]>; Rønningstad,
> > 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
> >
> > > Rønningstad, Øyvind <[email-masked]>; Brendan
> > > Do note that there are no valid use-cases for heavily truncated
> > > hashes in our information model. All hashes are exclusively used for
> security.
> > >   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
> > > https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcs
> > > rc
> > > .n
> > >
> > > algorithm-id-sha-512-256 digest-algorithm-ids /=
> > > algorithm-id-sha3-224 digest-algorithm-ids /= algorithm-id-sha3-256
> > > digest-algorithm-ids /=
> > > 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".
> > >
> > > > To: Rønningstad, Øyvind <[email-masked]>;
> > > > Brendan Moran <[email-masked]>; [email-masked]
> > > > > 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.
> > > >
> > > > Information Hash Algorithm Registry". It would be good if this
> > > > draft directly references the "Named Information Hash Algorithm
> Registry"
> > > > 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

---

From: Kvamtrø, Frank Audun <[email-masked]>
Date: Mon, 15 Apr 2019 07:43:28 +0000

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.

> Sent: 12. april 2019 16:55
> 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
> 
> 
> 
> > Total agreement on finding stable curated list, and hopefully this is
> > a list that can be one named "secure hashes" corresponding to active
> standards.
> >
> > 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.
> >
> > > 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.
> > >
> > > > Where we source the list to use in manifest of the hash types is
> > > > the big question...
> > > >
> > > > 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-sha3-224 digest-algorithm-ids /=
> > > > algorithm-id-sha3-256 digest-algorithm-ids /=
> > > > > directly to provide for future agility as new algorithms are
> > > > > added and use of specific algorithms fall out of practice. The
> "status"
> > > > > 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

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Apr 2019 10:31:10 -0400

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 <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 20 Apr 2019 00:47:49 -0500

> 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 ind…

Jumping in late, but this is basically what's going on in
draft-housley-hkdf-oids.  If we need to do it, it can be done.

-Ben