Re: [Rats] Robert Wilton's Discuss on draft-ietf-rats-eat-21: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi!

> -----Original Message-----
> From: RATS <[e-mail]> On Behalf Of Smith, Ned
> Sent: Thursday, September 7, 2023 1:24 PM
> To: Robert Wilton <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Rats] Robert Wilton's Discuss on draft-ietf-rats-eat-21: (with
> DISCUSS and COMMENT)
> 
> BTW: [RATS.Architecture] is now RFC9334. Regardless of whether it is
> informative or normative, the reference should be updated.

Agreed.

> I believe it is informative because RFC9334 is an informative RFC.

The status of RFC9334 won't dictate whether it is normative or informative in this document.  Referenced normatively in this document just makes RFC9334 a "DownRef" (i.e., a "higher status" proposed standard document referencing a "lower status" information document)

Borrowing from https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/, the key question is whether [RATS.Architecture] is needed to implement this RFC. 

The text in Section 9.3 of this documents meets that threshold of being "required reading" by pointing this document to the security considerations in [RATS.Architecture].  

==[ snip ]==
9.3.  Freshness

   All EAT use MUST provide a freshness mechanism to prevent replay and
   related attacks.  The extensive discussions on freshness in
   [RATS.Architecture] including security considerations apply here.
==[ snip ]==

Roman

> On 9/7/23, 6:11 AM, "RATS on behalf of Robert Wilton via Datatracker" <rats-
> [e-mail] <mailto:[e-mail]> on behalf of
> [e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-rats-eat-21: Discuss
> 
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-
> ballot-positions/
> <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/>
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
> <https://datatracker.ietf.org/doc/draft-ietf-rats-eat/>
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> Hi,
> 
> 
> Thanks for this document. Sorry, I didn't have time to review this document
> that closely. I have flagged one issue for discussion to change the reference
> to the architecture document to being a normative reference. This would mean
> a
> downref, but should otherwise be an easy change to make. The rest of my
> comments are non-blocking.
> 
> 
> (1) p 71, sec 11.2. Informative References
> 
> 
> [RATS.Architecture]
> Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
> W. Pan, "Remote ATtestation procedureS (RATS)
> Architecture", Work in Progress, Internet-Draft, draft-
> ietf-rats-architecture-22, 28 September 2022,
> <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
> <https://datatracker.ietf.org/doc/html/draft-ietf-rats->
> architecture-22>.
> 
> 
> "From section 1.3, EAT follows the operational model described in Figure 1 in
> [RATS.Architecture].". This, along with other references indicates that the
> RATS architecture should be a normative reference.
> 
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> (2) p 0, sec
> 
> 
> An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
> attestation-oriented claims.
> 
> 
> This is probably contentious, but given that this is a new spec, I wonder
> whether it wouldn't be better (i.e., encourage wider interop) if only CBOR,
> COSE and CWT were used/allowed.
> 
> 
> (3) p 20, sec 4.2.6. swname (Software Name) Claim
> 
> 
> The "swname" claim contains a very simple free-form text value for
> naming the software used by the entity. Intentionally, no general
> rules or structure are set. This will make it unsuitable for use
> cases that wish precise naming.
> 
> 
> I found it interesting, and slightly surprising, that the hardware model claim
> is opaque, but the software name claim is not.
> 
> 
> (4) p 24, sec 4.2.11. uptime (Uptime) Claim
> 
> 
> The "uptime" claim MUST contain a value that represents the number of
> seconds that have elapsed since the entity or submodule was last
> booted.
> 
> 
> Relative to other claim descriptions, the MUST in this description seems
> strange. Perhaps better as just "The "uptime" claim contains a value ..."
> 
> 
> (5) p 88, sec Appendix B. UEID Design Rationale
> 
> 
> A UEID is not a UUID [RFC4122] by conscious choice for the following
> reasons.
> 
> 
> Note that the UUID spec is currently being updated (it is also on this week's
> telechat review), so some of the concerns being described here may no longer
> be
> valid. It is still only 128 bits though, and 6 bits are spent identifying UUID
> format and version.
> 
> 
> (6) p 89, sec Appendix B. UEID Design Rationale
> 
> 
> Note also that that a type 2 UEID (EUI/MAC) is only 7 bytes compared
> to 16 for a UUID.
> 
> 
> Note that the paragraph at the end of appendix B.1. states that UEIDs are a
> minumum of 128 bits ...
> 
> 
> Regards,
> Rob
> 
> 
> 
> 
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats
> <https://www.ietf.org/mailman/listinfo/rats>
> 
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats