Re: [Suit] AD Review of draft-ietf-suit-mud-04

Hi Roman,

thanks for the extra feedback. Responses inline:

Am 23.09.2023 um 00:41 schrieb Roman Danyliw:
> Hi Hannes!
>
> Thanks so much for publishing -05.  My remaining line of feedback is around my original questions about Section 3 –- the normative guidance around the workflow.  The new text in Section 3 on the steps in the workflow are much clearer, and I very much appreciated the pro/con write-up of the design in Section 4.  Not many specifications will write-up the cons.
>
> If I read things correctly, the Section 3 workflow is trying to mirror a new MUD conveyance approach like DHCP or LLDP.  What I’m grappling with is how interoperable is this attestation step as currently scoped?  EAT is cited normatively, but there are no other normative details on how this attestation should occur.
>
> Are there any requirements other than an “EAT token with a manifest claim is somehow passed”?
>
> Is there any guidance on conveyance?  For example, EAP is mentioned (as an example).  Is there a pointer on how an EAT can be carried by an EAP method?

Currently, this attestation step is not interoperable. While there is
the need to convey an EAT token in an EAP method exchange, I haven't
seen such an EAP method yet.

Theoretically, one could argue that the work in
<draft-fossati-tls-attestation> could be applied to an EAP-TLS-based
method but nobody has done this work yet.

>
> Related to what “attestation” means, is the subsequent text in Section 4: “The device does not report the MUD URL, so the device cannot tamper with the MUD URL.”  I took that to mean that there is a distinction being made between TEE and a REE; and the “device” here is the REE. Is that intended interpretation?

I think the text needs a picture. There is the underlying assumption
with the use of attestation technology that some low-level
software/hardware is able to collect measurements from about its
environment. When that software generates the attestation evidence for
use with remote attestation then it includes information about the
manifest. When using the SUIT manifest, the attester will hopefully
verify also the firmware the SUIT manifest describes.

>
> If accurate, I recommend explicitly clarifying this.  Section 1.1 of draft-ietf-rats-eat-21 seems to lay out uses of EAT which are not TEE based.  A quick scan of draft-ietf-suit-architecture found definitions for TEE and REE, but (with using a keyword search only) REE is never used after it is defined, and TEE is used once in Section 6 without direct guidance on use.

The RATS architecture does not say where some of the functionality is
implemented. The attester-functionality needs to be provided by some
low-level software, which would be close to a TEE in the TEEP terminology.

To summarize, this document is something you could describe as more
forward looking than the other SUIT items.

Ciao
Hannes

>
> Thanks,
> Roman
>
>> -----Original Message-----
>> From: Suit <suit-bounces@ietf.org> On Behalf Of Hannes Tschofenig
>> Sent: Sunday, September 10, 2023 10:59 AM
>> To: Roman Danyliw <rdd@cert.org>; suit@ietf.org
>> Subject: Re: [Suit] AD Review of draft-ietf-suit-mud-04
>>
>> Hi Roman,
>>
>>
>> those are great review comments.
>>
>>
>> I have started to address them, see
>> https://github.com/bremoran/suit-mud/pull/5
>>
>>
>> You have certainly discovered the weakness of this proposal. It relies on a
>> number of technologies to be in place before it can actually be deployed. When
>> those conditions are met, there are security and operational benefits. I made
>> this more clear in the write-up.
>>
>>
>> Ciao
>>
>> Hannes
>>
>>
>> PS: Only the MUD URL is included in the manifest and not the MUD file itself.
>> Your reading of the CDDL was correct.
>>
>>
>> Am 09.09.2023 um 22:18 schrieb Roman Danyliw:
>>> Hi!
>>>
>>> I performed an AD review of draft-ietf-suit-mud-04.  Thanks for this
>> document.  Below is my feedback.
>>> ** Section 1 and 6 assert that a MUD file can be included by reference or
>> value.  How does one include a MUD file by value?  Excuse my familiarity with
>> CDDL but my read of SUIT_MUD_container is that is contains only a URL and
>> associate SKI.  All of the other CDDL in Section 5 by my read is about
>> integrating the SUIT_MUD_container data structure so it can be as a manifest
>> member or be severable.
>>> ** Section 3.  I was confused on how to read this section.  I was
>>> expecting this document to primarily discuss how to embed MUD
>>> information into a SUIT manifest.  However, this section seems to
>>> define attestation behavior and functionality on the end-point that is
>>> outside the SUIT workflow and more rigorous than required in the core
>>> SUIT manifest document.  Is this section normative or just an example?
>>> [I-D.ietf-rats-eat] being cited normatively here suggests the section
>>> is also normative.  If this is an example, please make that clearer
>>> and don’t make EAT a normative reference.  If not, then please be more
>>> specification about these attestation mechanisms (more below)
>>>
>>> ** Section 3.
>>>
>>>      *  At the time of onboarding, devices report their manifest in use to
>>>         the MUD manager via attestation evidence.
>>>
>>> Can a pointer please be provided on the normative mechanism for sharing
>> attestation evidence with the MUD manager?  I ask because RFC8520 doesn’t
>> mention attestation as an activity done by the MUD manager.
>>>      *  If the SUIT_MUD_container, see Section 5, has been severed, the
>>>         MUD manager can use the suit-reference-uri to retrieve the
>>>         complete SUIT manifest.
>>>
>>> What happens if suit-reference-uri is not included?  If my reading of draft-
>> ietf-suit-manifest-22 is correct, this field is optional.
>>>      *  Each time a device is updated, rebooted, or otherwise
>>>         substantially changed, it will execute an attestation.
>>>
>>> Is this new requirement on any device including this MUD extension?
>>>
>>>         -  Among other claims in the Entity Attestation Token (EAT)
>>>            [I-D.ietf-rats-eat], the device will report its software
>>>            digest(s), configuration digest(s), manifest URI, and manifest
>>>            digest to the MUD manager.
>>>
>>> What is the profile of the EAT claims needed?  How is it conveying this EAT
>> token?
>>>      *  If the MUD manager does not already have a full copy of the
>>>         manifest, it can be acquired using the reference URI.
>>>
>>> When the manifest was retrieved in step #2 is was verified in step #3.  Here,
>> there is no explicit language about verification.
>>>      *  Once a full copy of the manifest is provided, the MUD manager can
>>>         verify the device attestation report
>>>
>>> Wouldn’t the device have to emit the device attestation report?
>>>
>>> ** Section 5.  To be clear, suit-mud-ski is the subject key identifier for the key
>> used in the MUD signature file described in Section 13.2 of RFC8520?  If so,
>> editorial, I would have benefited from an explicit statement to that effect.
>>> ** Section 6.  Do any Security Considerations from suit-manifest or MUD
>> apply here?
>>> ** Reference
>>>
>>> --  [I-D.isobe-cose-key-thumbprint] is now adopted by the WG and is draft-
>> ietf-cose-key-thumbprint.  Please replace it.
>>> -- feedback from idnits:
>>>     == Unused Reference: 'RFC7093' is defined on line 288, but no explicit
>>>        reference was found in the text
>>>
>>>     ** Downref: Normative reference to an Informational RFC: RFC 7093
>>>
>>> Please drop it.
>>>
>>> Regards,
>>> Roman
>>> _______________________________________________
>>> Suit mailing list
>>> Suit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/suit
>> _______________________________________________
>> Suit mailing list
>> Suit@ietf.org
>> https://www.ietf.org/mailman/listinfo/suit
> _______________________________________________
> Suit mailing list
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit