Subject: [Suit] Mandatory To Implement Set of Algorithms

From: <[email-masked]>
Date: Fri, 2 Mar 2018 10:47:29 +0000

Hannes,

I added my initial comments/thinking regarding your suggestion, question on Mandatory Set To Implement Set of Algorithms marked with [mg].

This is a new topic for me, and may require a bit more thinking (on my side)

Thanks,

Markus

[hannes] Good points. What about adding this paragraph to Section 3.3:

"

The use of post-quantum secure signature mechanisms, such as hash-based signatures, should be explored. A mandatory-to-implement set of algorithms has to be defined offering a key length of 112-bit symmetric key or security or more, as outlined in Section 20 of RFC 7925. This corresponds to a 233 bit ECC key or a 2048 bit RSA key.

"

[mg] My motivation was to suggest more details in this section by specifying a minimum security level, and referring to 112-bit symmetric key and section 20 of RFC 7925 sounds good.

However I am not sure about the 'mandatory-to-implement' part, since this is in my opinion is a different and completely new topic and has more implications. Also see my next comment

Therefore I would prefer to adapt your suggested text and remove the 'mandatory-to-implement' for the architecture under the heading 'Uses state-of-the-art security mechanisms':

" The use of post-quantum secure signature mechanisms, such as hash-based signatures, should be explored. A minimum key length of 112-bit symmetric key or security OR more, as outlined in Section 20 of RFC 7925 shall be used. This corresponds to a 233 bit ECC key or a 2048 bit RSA key."

Would this be ok?

I am open for suggestions on better wording of the post quantum secure algorithms support.

I would add specific mandatory-to-implement algorithms in the manifest format itself. I would say something like MUST implement ECC with NIST P-256r1, AES-128-CCM, and SHA256. As an SHOULD implement I would use Ed25519, CHACHA20-POLY1305 and SHA256 (which seems to be close to what TLS 1.3 is recommending). Does this sound reasonable to you?

[mg] Regarding a _mandatory_  Algorithm Set in the manifest I have one question/potential concern:

What if an Device vendor is required (for whatever reason) to implement a 'higher' Algorithm Set (e.g. ECC NIST-P521, AES-256-CCM, SHA-512) to protect the update solution for his devices.

Based on your MUST statement I interpret that he still be required to implement and accept updates with a lower security, making his SUIT IoT Solution more unsecure in the context of Bits of Security/ Key Length.

I am not sure if my understanding is correct, if yes then I am reluctant that IETF specifies the one _mandatory_ to implement Algorithm Set.

In general the definition of Algorithm Sets (e.g. or something like SUIT Ciphersuits) might be helpful and a good idea to have a basis for interoperability between 'Author Systems' and IoT Devices.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 3 Mar 2018 07:05:17 +0000

Hi Markus,

Comments below.

~snip~

Maybe this is a thread we should also add to the document where a device is tricked into using an old, potentially insecure algorithm. There is an extreme case we have seen with JSON signatures where one of the allowed signature mechanisms was "none" and implementations didn't check whether this was actually allowed.

I would assume that a device has a policy that indicates what algorithms it finds acceptable and what not. Of course, there is a challenge with  mandatory-to-implement algorithms in a practical sense for constrained devices. There are a few ways to deal with this, such as

*       No mandatory-to-implement algorithms

*       Use of mandatory-to-implement algorithms unless there is an application/usage profile that says something else. In your example the different key size may be a requirement from a specific sector.

*       Having different sets of MTI profiles.

That was also my thinking. I was also thinking about the case where there are multiple signers.

Ciao

Hannes

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.