Subject: [Suit] Integrated payload sizes

From: Brendan Moran <[email-masked]>
Date: Tue, 19 Nov 2019 15:05:27 +0000

Having considered the payload size question a bit more, I think that I’m now in the position to make a recommendation to the list on setting minimum required payload sizes.

The suit-information-model is supposed to contain requirements in abstract and not in specific. Therefore, I think that the suit-information-model should contain the sections listed below.

These changes are present in a PR on the suit-wg GitHub: https://github.com/suit-wg/information-model/pull/5

I don’t currently see a good reason to set a minimum manifest buffer size (which would belong in draft-ietf-suit-manifest), however that is a discussion that can continue independent of the information model if there are objections.

Best Regards,
Brendan

An explicit TOC/TOU threat, which is the root of this discussion.

### THREAT.MFST.TOCTOU: Modification of manifest between authentication and use {#threat-mfst-toctou}

Classification: All Types

If an attacker can modify a manifest after it is authenticated (Time Of Check) but before it is used (Time Of Use), then the attacker can place any content whatsoever in the manifest.

Mitigated by: [REQ.SEC.MFST.CONST](#req-sec-mfst-const)

A requirement to keep the manifest immutable between check and use.

### REQ.SEC.MFST.CONST: Manifest kept immutable between check and use {#req-sec-mfst-const}

The manifest MUST be held immutable between its time of check and time of use. To make this guarantee, the manifest MUST fit within an internal memory or a secure memory. The recipient SHOULD defend the manifest from tampering by code or hardware resident in the recipient, for example other processes or debuggers.

If an application requires that the manifest is verified before storing it, then this means the manifest MUST fit in RAM.

Mitigates: [THREAT.MFST.TOCTOU](#threat-mfst-toctou)

A note about what kind of payloads constitute a “small payload"

### USER_STORY.MFST.IMG: Payload in Manifest {#user-story-mfst-img}

As an operator of devices on a constrained network, I would like the manifest to be able to include a small payload in the same packet so that I can reduce network traffic.

Small payloads may include, for example, wrapped encryption keys, encoded configuration, public keys, {{RFC8392}} CBOR Web Tokens, or X.509 certificates.

Satisfied by: [REQ.USE.PAYLOAD](#req-use-payload)

A note about expected uses of integrated payloads and a note about the security requirement for maintaining the integrity of the manifest between ToC and ToU.

### REQ.USE.PAYLOAD: Payload in Manifest Superstructure {#req-use-payload}

It MUST be possible to place a payload in the same structure as the manifest. This MAY place the payload in the same packet as the manifest.

Integrated payloads may include, for example, wrapped encryption keys, encoded configuration, public keys, {{RFC8392}} CBOR Web Tokens, or X.509 certificates.

See also: [REQ.SEC.MFST.CONST](#req-sec-mfst-const).

Satisfies: [USER_STORY.MFST.IMG](#user-story-mfst-img)

Implemented by: [Payload](#manifest-element-payload)

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.