Hi Russ, Thanks for the review. I have created a few PR based on your comments: https://github.com/ietf-teep/architecture/pull/234 I have added a few remarks below (mainly agreeing with your observations). Ciao Hannes -----Original Message----- From: Russ Housley via Datatracker <noreply@xxxxxxxx> Sent: Tuesday, March 29, 2022 12:08 AM To: art@xxxxxxxx Cc: draft-ietf-teep-architecture.all@xxxxxxxx; last-call@xxxxxxxx; teep@xxxxxxxx Subject: Artart last call review of draft-ietf-teep-architecture-16 Reviewer: Russ Housley Review result: Almost Ready I am the assigned ARTART reviewer for this Internet-Draft. Document: draft-ietf-teep-architecture-16 Reviewer: Russ Housley Review Date: 2022-03-28 IETF LC End Date: 2022-04-07 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: None. Minor Concerns: Section 3.3 says: Weak security in Internet of Things (IoT) devices has been posing threats to critical infrastructure that relies upon such devices. I'm a bit confused by this opening sentence. IoT devices usually depend upon an infrastructure. This seems to be talking about an infrastructure that depends upon a collection of IoT devices. I suggest a minor edits to help the reader understand that this sentence is not talking about network infrastructure. [Hannes] I have changed the sentence to improve the wording. Section 9.3 says that a compromised REE "might drop or delay messages". This discussion should be expanded to include the replay of messages. [Hannes] Agree. Section 9.4 says: A root CA for TAM certificates might get compromised or its certificate might expire, or a Trust Anchor other than a root CA certificate may also expire or be compromised. I do not understand the difference between a Root CA and a Trust Anchor. These are usually used a synonyms. Please explain the difference that in intended here. [Hannes] Good point. I removed part of the sentence. Nits: Section 1 says: ... The problems in the bullets above, on the other hand, require a new protocol, i.e., the TEEP protocol, for TEEs that can install and enumerate TAs in a TEE-secured location and where another domain-specific protocol standard (e.g., [GSMA], [OTRP]) that meets the needs is not already in use. Recommend breaking this long sentence up into at least two sentences. There are two points. First, the need for a protocol to address the items listed earlier. Second, where an existing domain-specific protocol does not already exist, a new more general protocol is needed. [Hannes] Splitting the sentence improves readability. Section 4.4 says: ... Implementations must support encryption of such Personalization Data to preserve the confidentiality of potentially sensitive data contained within it, and must support integrity protection of the Personalization Data. Why not say that implementation must support mechanisms for the confidentiality and integrity protection of such Personalization Data? Also, it seems like draft-ietf-suit-firmware-encryption offers one mechanism for such protection. Should it be referenced here? [Hannes] Agree that the sentence should be simplified. You are also right by saying that a solution is available. I am not sure we should reference the solution in this document or in the protocol spec. Section 4: Is an "App Store" a place where apps are stored, or is it a place where apps a purchased? The term seems to be used both ways, and in one place, the document is very general by saying, "an app store or other app repository". Elsewhere, the term "Trust Anchor Store" is clearly a place for storage of trust anchors. [Hannes] I am not entirely sure what do about this one. I hope for input from my co-authors. Section 9.7: Please consider changing the section title to be something like: "TEE Certificate Expiry and Renewal". There is an earlier section that talks about expiration of Root CA certificates. [Hannes] Makes sense. 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
