[secdir] Re: draft-ietf-suit-report-14 ietf last call Secdir review

[Brendan Moran <[e-mail]>]

Hi Russ,

Thank you for your review. I have now published
draft-ietf-suit-report-15, which I believe addresses the issues
identified in this review.

Please see my comments, inline.

Best Regards,
Brendan

On Thu, Aug 7, 2025 at 10:20 PM Russ Housley via Datatracker
<[e-mail]> wrote:
>
> Document: draft-ietf-suit-report
> Title: Secure Reporting of Update Status
> Reviewer: Russ Housley
> Review result: Not Ready
>
> I reviewed this document as part of the Security Directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Security Area
> Directors.  Document authors, document editors, and WG chairs should
> treat these comments just like any other IETF Last Call comments.
>
> Document: draft-ietf-suit-report-14
> Reviewer: Russ Housley
> Review Date: 2025-08-07
> IETF LC End Date: 2025-08-11
> IESG Telechat date: Unknown
>
> Summary: Not Ready
>
>
> Major Concerns:
>
> Section 5: I do not understand the meaning of "Manifest Processor & Report
> Generator". This is part of a MUST statement, and it is unclear what is
> required.

The new language for this section follows. I believe that it is
clearer and should resolve this concern.

For the SUIT_Report to be usable as Attestation Evidence, the
environment that generated the SUIT_Report also needs to be measured.
Typically, this means that the software that executes the commands in
the Manifest (the Manifest Processor) must be measured; similarly, the
piece of software that assembles the measurements, taken by the
Manifest Processor, into the SUIT_Report (the Report Generator) must
also be measured. Any bootloaders or operating systems that facilitate
the running of the Manifest Processor or Report Generator also need to
be measured in order to demonstrate the integrity of the measuring
environment.

Therefore, if a Remote Attestation format that conveys Attestation
Evidence, such as an Entity Attestation Token (EAT, see [RFC9711]),
contains a SUIT_Report, then it MUST also include an integrity
measurement of the Manifest Processor, the Report Generator and any
bootloader or OS environment that ran before or during the execution
of both.


> Section 5: The last paragraph begins with "This information is not intended".
> I cannot determine what information is being referenced, , and it is unclear
> what SHOULD be translated into general-purpose claims.

This paragraph has been substantially expanded. Instead of vague
statements, the language is now more precise. Hopefully the new
language, below, will resolve this concern.

For a Verifier to consume the SUIT_Report, it requires a copy of the
SUIT_Manifest. The Verifier then replays the SUIT_Manifest, using the
SUIT_Report to resolve whether each condition is met. It identifies
each measurement that is required by attestation policy and records
this measurement as an Attestation Claim. It evaluates whether the
SUIT_Report correctly matches the SUIT_Manifest as an element of
evaluating trustworthiness. For example there are several indicators
that would show that a SUIT_Report does not match a SUIT_Manifest. If
any of the following (not an exhaustive list) occur, then the Manifest
Processor that created the report is not trustworthy:

* Hash of SUIT_Manifest at suit-report-manifest-uri does not match
suit-report-manifest-digest
* A SUIT_Record is issued for a SUIT_Command_Sequence that does not
exist in the SUIT_Manifest at suit-report-manifest-uri.
* A SUIT_Record is identified at an offset that is not a condition and
does not have a reporting policy that would indicate a SUIT_Record is
needed.

Many architectures require multiple Verifiers, for example where one
Verifier handles hardware trust, and another handles software trust,
especially the evaluation of software authenticity and freshness. Some
Verifiers may not be capable of processing a SUIT_Report and, for
separation of roles, it may be preferable to divide that
responsibility. In this case, the Verifier of the SUIT_Report should
perform an Evidence Transformation [I-D.ietf-rats-evidence-trans] and
produce general purpose Measurement Results Claims that can be
consumed by a downstream Verifier, for example a Verifying Relying
Party, that does not understand SUIT_Reports.

> Section 7: This section does not have any information that will assist an
> implementer.  It does not explain what makes an EAT measurements type
> more consumable than a SUIT_Report on its own.  If this section is kept,
> it should include a reference to EAT; the reference is several pages earlier.

In combination with the above, Section 7 has been expanded as follows:

The Entity Attestation Token (EAT, see [RFC9711]) is a secure
container for conveying Attestation Evidence, such as measurements,
and Attestation Results. The SUIT_Report is a form of measurement done
by the SUIT Manifest Processor as it attempts to invoke a manifest or
install a manifest. As a result, the SUIT_Report can be captured in an
EAT measurements type.

The log-based structure of the SUIT_Report is not conducive to
processing by a typical Relying Party: it contains only a list of
waypoints through the SUIT Manifest--unless system parameter records
are included--and requires additional information (the SUIT_Manifest)
to reconstruct the values that must have been present at each test. A
Verifier in possession of the SUIT_Manifest can reconstruct the
measurements that would produce the waypoints in the SUIT_Report. The
Verifier SHOULD convert a SUIT_Report into a more consumable version
of the EAT claim by, for example, constructing a measurement results
claim that contains the digest of a component, the vendor ID & class
ID of a component, etc.

>
> Minor Concerns:
>
> Section 4: It is not clear which algorithm will be used to compute
> the SUIT_Digest.  The structure is defined in [I-D.ietf-suit-manifest],
> and I copy it here:
>
>    SUIT_Digest = [
>      suit-digest-algorithm-id : suit-cose-hash-algs,
>      suit-digest-bytes : bstr,
>      * $$SUIT_Digest-extensions
>    ]
>
> For example, is the party that produces the SUIT_Reference that contains
> the SUIT_Digest expected to use the same hash algorithm as was used in
> the SUIT_Manifest?

This is now is spelt out explicitly:

suit-report-manifest-digest provides a SUIT_Digest (as defined in
[I-D.ietf-suit-manifest]) that is the characteristic digest of the
Root manifest. This digest MUST be the same digest as is held in the
first element of SUIT_Authentication in the referenced
Manifest_Envelope.

> Section 5: What does the term "well-informed" really mean here? I read
> the sentence without this term an come away with the same understanding.
> Can this be dropped?

Yes, you are right. This probably could be dropped. Unfortunately, I
missed that in the latest version. Would you like an update to address
this?

> Nits:
>
> Section 3: s/well, however this/well; however, this/

Fixed.

> Section 4: s/of SUIT_Records/of SUIT_Records as defined in Section 3/

Fixed.

> Section 5: s/SUIT_report/SUIT_Report/

Fixed.

>
>
>