From nobody Tue Dec 1 20:26:37 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 730003A03AA; Tue, 1 Dec 2020 20:26:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-suit-information-model@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Dave Thaler , dthaler@microsoft.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160688319501.32527.12585051445492218443@ietfa.amsl.com> Date: Tue, 01 Dec 2020 20:26:35 -0800 Archived-At: Subject: [Suit] Barry Leiba's No Objection on draft-ietf-suit-information-model-08: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 04:26:35 -0000 Barry Leiba has entered the following ballot position for draft-ietf-suit-information-model-08: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is good work, and thanks for doing it. I only have a few very minor comments: — Section 3.3.1 — vendorId = UUID5(DNS, "vendor-a.com") Please use a BCP 32 domain name reserved for examples in documentation, here and throughout. I suggest “vendor-a.example” here. — Section 3.15 — It is NOT REQUIRED for a serialization to authenticate multiple manifests with a single Signature element. “NOT REQUIRED” is not a BCP 14 key word. I suggest just making the two words lower case. Also in Section 3.24. — Section 4.5.11 — 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. The MAY appears to be a statement, not a protocol option, and should be “may” (or “might”). From nobody Wed Dec 2 09:11:32 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA21D3A14DC; Wed, 2 Dec 2020 09:11:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell via Datatracker To: Cc: draft-ietf-suit-information-model.all@ietf.org, suit@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160692908365.17795.15632727578874174380@ietfa.amsl.com> Reply-To: Stephen Farrell Date: Wed, 02 Dec 2020 09:11:23 -0800 Archived-At: Subject: [Suit] Iotdir telechat review of draft-ietf-suit-information-model-08 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 17:11:24 -0000 Reviewer: Stephen Farrell Review result: Ready with Issues I think this is probably ready but wanted to just check one thing. The draft seems overly prescriptive in some places. I think that's ok though as it's the CBOR spec that'd affect interop so is where such issues should be addressed. Is that right? If so, that's fine. If however, the MUSTs in this draft are supposed to be slavishly followed then I think a non-trivial number of then are wrong. Just to pick out a couple of examples: 4.3.1: "Devices MUST reject manifests with sequence numbers smaller than any onboard sequence number." I'm not sure it's ok to rule out rollback without a new manifest in all cases. Is there evidence that that is ok? 4.3.6: Why MUST that location be explicit in the manifest? It could be an installation parameter in some cases, e.g. use SD card if present, else use on-board flash, and all might depend on space available and boot order settings. Note that even though I disagree with some of those MUSTs, the draft would still be fine and useful so long as those aren't taken too seriously:-) a couple of nits: abstract: s/must be present/can be present/ ? 3.20: Expand XIP on 1st use From nobody Wed Dec 2 22:37:52 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DFA3A048B; Wed, 2 Dec 2020 22:37:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-suit-information-model@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Dave Thaler X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <160697746988.11643.5723509584593503405@ietfa.amsl.com> Date: Wed, 02 Dec 2020 22:37:50 -0800 Archived-At: Subject: [Suit] Murray Kucherawy's No Objection on draft-ietf-suit-information-model-08: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 06:37:50 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-suit-information-model-08: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The "Special consideration ..." paragraph in Section 3.7 seems to be improperly split. In Section 3.8, isn't "This element is REQUIRED and MUST be present" redundant? (Also in Section 3.10, possibly later too.) Is it legitimate that Section 4.4.3 satisfies itself? From nobody Wed Dec 2 22:45:38 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9E23A0644; Wed, 2 Dec 2020 22:45:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-suit-information-model@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Dave Thaler , dthaler@microsoft.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160697793727.715.182823460960781249@ietfa.amsl.com> Date: Wed, 02 Dec 2020 22:45:37 -0800 Archived-At: Subject: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-information-model-08: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 06:45:37 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-suit-information-model-08: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (I did not attempt to cross-check that the forward- and backward- references among threats and mitigating requirements and manifest (envelope) elements are consistent. That said, I did by accident find one instance of apparent inconsistency, noted inline, so a dedicated pass to check these seems in order.) I'll also briefly mention here that I left a longer note about the delegation chain appearing to be a bit underspecified; that's probably the most important of my comments (the document in general is in good shape). Section 1 The information model describes all the information elements required to secure firmware updates of IoT devices from the threats described in Section 4.1 and enables the user stories captured in Section 4.4. The Introduction has to stand on its own, without the context of the Abstract. So, having the document start off like this is not great writing style; there's no previous discussion to justify the definite article in "the information model", for one, and we start off by just forward-referencing that other sections will do some things. Including the entire abstract contents wholesale before this would be a decent start, though additional editing is expected to be in order (the abstract and introduction play different roles and generally the one is not a strict subset of the other). Section 2 Secure time and secure clock refer to a set of requirements on time sources. For local time sources, this primarily means that the clock must be monotonically increasing, including across power cycles, firmware updates, etc. [...] But it doesn't have to be anywhere close to an actual reference time source, just monotonic? Section 3.3 identically named entities from different geographic regions from colliding in their customer's infrastructure. Recommended practice is to use [RFC4122] version 5 UUIDs with the vendor's domain name and the DNS name space ID. Other options include type 1 and type 4 UUIDs. We should probably pick one of 'version' and 'type' when referring to the UUID constructions. Section 3.4 Does "more granular" mean more fine-grained or more coarse-grained? Section 3.6 When a payload applies to multiple versions of a firmware, the required image version list specifies which versions must be present for the update to be applied. This allows the update author to It's really hard for me to parse "which versions must be present" as anything other than "there can be multiple versions present at the same time and all of the listed versions must be present", even though I suspect that the intent is that "the single version that is currently installed must be in the list of required versions". Section 3.10.2 A device supports a full filesystem. The Author chooses to use the nit: I suggest "full-featured filesystem", since "full filesystem" can be used to mean "a filesystem with no free space". Section 3.12 Where is "the resource" defined? I don't see it in this doc or in the architecture doc. The antepenultimate paragraph suggests that it is intended to be synonymous with the 'payload'... Section 3.15 This element is REQUIRED in non-dependency manifests and represents the foundation of all security properties of the manifest. Manifests which are included as dependencies by another manifest SHOULD include a signature so that the recipient can distinguish between different actors with different permissions. nit: maybe add a few more words to clarify that the actors being distinguished are the signers (authors?) of the various manifest contents? Section 3.16 I assume since this is IoT that the "additional installation instructions" will need to be machine-readable, but "install on sunday at 0200" and other examples could lead the reader to expect something human readable, especially when "run a script" is included as a separate option. It might be worth a bit of clarification. Section 3.18 A list of other manifests that are required by the current manifest. Manifests are identified an unambiguous way, such as a digest. "cryptographic digest" might be needed to ensure the desired property. Section 3.21 I'm not entirely sure what unqualified "source" and "destination" are intended to refer to in the context of loading a firmware image. Section 3.24 I don't think the text here is enough to give a picture of what the delegation chain is supposed to do. Later discussion suggests that it is a way to change or augment the set of entities authorized to sign (top-level) manifests, but this text seems to just talk about "authorization functionality" and not what is being authorized. (It also doesn't talk about what trust anchor the crypto chains to and whether it needs to be the same thing that the manifest signatures chain to, but that is perhaps excusable in an information model.) Section 4 We should probably mention the URI security considerations (RFC 3986) somewhere, as well as that remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs. We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed. It might also be worth reiterating the topic that came up during one of the other review threads: firmware update is *by definition* remote code execution, so if you trust an entity to provide your firmware, you are trusting them to do the right thing. Many classes of attack involving malicious or modified payloads then become irrelevant, so we are left with just needing to verify that it did come from a trusted party and is not going backwards, topics that are covered quite well already (including TOCTOU). Section 4.2 A bit of intro for the format of each subsection might be helpful; e.g., the optional presence of the "Threat Escalation" portion took me some time to understand. Section 4.2.9 If an attacker can install their firmware on a device, by manipulating either payload or metadata, then they have complete This feels like an "e.g." kind of thing, with payload and metadata modification not necessarily being an exhaustive list of ways to get an attacker's firmware on a device. Section 4.2.11.1 This is a denial of service because it can render devices inoperable. This is an elevation of privilege because it allows the attacker to make installation decisions that should be made by the Operator. In this example it seems like the decision was supposed to have been made by the Network Operator specifically, but perhaps I misunderstand. Section 4.3.4 The authenticity of an update MUST be demonstrable. Typically, this means that updates must be digitally authenticated. Because the manifest contains information about how to install the update, the manifest's authenticity MUST also be demonstrable. To reduce the overhead required for validation, the manifest contains the digest of the firmware image, rather than a second digital signature. The authenticity of the manifest can be verified with a digital signature or Message Authentication Code. The authenticity of the firmware image is tied to the manifest by the use of a digest of the firmware image. I suggest "cryptographic digest" here as well (twice). Section 4.3.5 Implemented by: Payload Format (Section 3.8), Storage Location (Section 3.10) I know I said I didn't try to cross-check these (which is true!), but I did notice that "Storage Location" was a bit funny for implementing an authenticated payload type, and indeed §3.10 does not mention REQ.SEC.AUTH.IMG_TYPE. Section 4.3.16 Status reports from the device to any remote system SHOULD be performed over an authenticated, confidential channel in order to prevent modification or spoofing of the reports. Why is this only SHOULD (not MUST)? Sections 4.3.16-4.3.20 None of these have "Implemented by" lines. Should they? Section 4.4.1 o Use a table of hashes to ensure that each block of the payload is validate before writing. nit: either "valid" or "validated". Section 4.4.7 As a firmware author, I want to prevent confidential information from being disclosed during firmware updates. It is assumed that channel security or at-rest encryption is adequate to protect the manifest itself against information disclosure. This is the "image confidentiality" section, so I'm not sure why we're talking about protecting the manifest itself. Section 4.5.3 Implemented by Manifest Element: Dependencies, StorageIdentifier, ComponentIdentifier (nit?) should this just be "Implemented by:"? Section 4.5.3.1 An IoT device with multiple microcontrollers in the same physical device (HeSA) will likely require multiple payloads with different component identifiers. Please expand HeSA. Section 4.5.9 systems. This requires the manifest to specify the digest of each statically linked dependency. In addition, the manifest format MUST I don't understand how this follows. Aren't statically linked dependencies incorporated into the image itself, in which case knowing their individual digest values serve no purpose? (Also, "cryptographic digest" again.) Section 4.5.12 The structure of the manifest MUST be simple to parse, without need for a general-purpose parser. I'm not sure what constitutes a "general-purpose parser" for this purpose. Section 7.1 RFCs 5652 and 8152 are in the context of a "such as" qualifier (even though it's for an overall MAY requirement), and as such probably don't strictly need to be classified as normative. From nobody Thu Dec 3 03:54:23 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACE93A0766; Thu, 3 Dec 2020 03:54:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-suit-information-model@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Dave Thaler , dthaler@microsoft.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160699645841.7068.8542217062832784146@ietfa.amsl.com> Date: Thu, 03 Dec 2020 03:54:18 -0800 Archived-At: Subject: [Suit] Robert Wilton's No Objection on draft-ietf-suit-information-model-08: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 11:54:19 -0000 Robert Wilton has entered the following ballot position for draft-ietf-suit-information-model-08: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank for your work on this document. Generally I found this document to fairly easy to read, although it did feel somewhat back to front, although this is probably just personal style. I.e., I think that I would have preferred for the security considerations section to describe the threat model and threats, but for all the requirements and user stories to be documented early in the document before the manifest elements are described. Other than the document structure, I also have a question regarding Vendor ID and Class ID. Both of these use UUIDs, but it wasn't really clear to me why UUIDs are better than using a domain and a string. I appreciate that the stated goal is that these don't need to be human readable, but does this mean that it is only the device and device owner who is able to determine whether a particular firmware is compatible with a particular device. Is it not potentially helpful to provide a hint to the user as to whether the firmware described by a manifest might be suitable for a given device, or is that information available in some other way? Regards, Rob From nobody Thu Dec 3 05:26:51 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3590B3A0A71; Thu, 3 Dec 2020 05:26:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-suit-information-model@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Dave Thaler , dthaler@microsoft.com, stephen.farrell@cs.tcd.ie X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160700200877.4128.3994275535906634718@ietfa.amsl.com> Date: Thu, 03 Dec 2020 05:26:49 -0800 Archived-At: Subject: [Suit] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-suit-information-model-08=3A_=28with_COMMENT=29?= X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 13:26:49 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-suit-information-model-08: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. It is easy to read and the examples are useful. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I draw authors' attention to my comment on section 4. Stephen Farrel, in copy, also did a IOT directorate review available at https://datatracker.ietf.org/doc/review-ietf-suit-information-model-08-iotdir-telechat-farrell-2020-12-02/ Thank you again Stephen Please address/reply to all his points. I hope that this helps to improve the document, Regards, -éric == COMMENTS == As usual, I find a little suprizing that an information model is "standards track" rather than "informational" (e.g., RFC 8454, draft-ietf-babel-information-model, draft-ietf-detnet-flow-information-model). Data models are of course "standards track". There are exceptions though: RFC 5477, 7012, and 8193 are informational model in standards track. Why is the word "manifest" absent of the title ? The companion data model document has it. -- Section 1 -- Two pedantic comments/questions: 1) "The information model describes all the information elements required..." should "relationships" be included in the sentence ? 2) "The information model does not define the serialization, encoding, ordering, or structure of information elements, only their semantics." is nearly a pleonasm as it should be obvious for an information model as opposed to a data model. -- Section 2.1 -- How much this section about "REQUIRED", ... definitions contradicts/overlaps with section 1 definition of those terms ? -- Section 3.1 -- "manifest format" does it refer to draft-ietf-suit-manifest, if so, then a reference is required and how is this format is described ? -- Section 3.2 -- "A monotonically increasing sequence number" should this number be unsigned ? What about rollover ? -- Section 3.1.1 & 3.4.2 & 3.4.4 (and possibly others) -- s/vendorId = UUID5(DNS, "vendor-a.com")/vendorId = UUID5(DNS, "vendor-a.exmaple.com")/ -- Section 3.8 -- Should the type of "format" be specified in the information model ? (e.g., as an enum or a string or ...) especially when Vendor ID element is very detailed as UUID. -- Section 3.13 -- While I am not a security expert, I would associate "integrity" (and not "authenticity") with a "digest" that is not a HMAC. But, I am trusting your SEC AD and his review ;-) -- Section 4 -- The train has left the station of course but I really wonder what is the relationship of this section to an information model. NB: I do like the content though ;-) -- Section 7.1 -- I wonder whether the reference to draft-ietf-suit-architecture (informational) is really normative. == NITS == There are a couple of missing ',' after some words "but" "instead" "e.g." "for example" "typically" "therefore" ;-) -- Section 3.5 -- Would "prerequisite" be more suitable than "precursor" ? From nobody Thu Dec 3 06:25:27 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8483A02BD; Thu, 3 Dec 2020 06:25:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-suit-information-model@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Dave Thaler , dthaler@microsoft.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <160700552141.28305.7634090465103290722@ietfa.amsl.com> Date: Thu, 03 Dec 2020 06:25:21 -0800 Archived-At: Subject: [Suit] Alissa Cooper's No Objection on draft-ietf-suit-information-model-08: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 14:25:22 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-suit-information-model-08: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General comment: I find the repetition of "Manifest Element:" in all the section headers redundant and would suggest removing it. = Section 3.3.1 = s/Vendor A creates a UUID based on their domain name:/Vendor A creates a UUID based on a domain name it controls:/ = Section 3.8 = "This element is REQUIRED and MUST be present" --> second normative keyword is redundant = Section 4.2.11 = The term "Owner," which is not defined in draft-ietf-suit-architecture, is sometimes capitalized as a term of art, and sometimes not. It seems like it should either be defined in this document and capitalized consistently, or not capitalized anywhere. (There is also one instance in Section 4.2.16). Network Operator is also not consistently capitalized. = Section 4.3.2 = "Devices MUST know with fine granularity" --> this requirement doesn't seem actionable as written, maybe re-phrase without the normative language? = Section 4.5 = In general I think it's preferable for normative statements to indicate which party is responsible for fulfilling them. Saying "It MUST be possible" can leave things ambiguous about who is supposed to take responsibility. It would be better to say "Manifest authors MUST ..." or something along those lines. From nobody Thu Dec 3 06:26:14 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D997C3A0BF2; Thu, 3 Dec 2020 06:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=HxxaFzK6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TpKJoLQn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUN3CwtY1mGx; Thu, 3 Dec 2020 06:26:10 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAACE3A0C57; Thu, 3 Dec 2020 06:26:10 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 018E35C0136; Thu, 3 Dec 2020 09:26:10 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 03 Dec 2020 09:26:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=H Dza7/683QCkX3H5eWrqv8InSpk2rLdn0mOGd46QIDU=; b=HxxaFzK6tDX54M1Bx fGIoaN2G5SP1HrUaQWD/6jeRtns5w/QrUKYrUNqAnJSLFbbiYvVBQPOGQkhljFKY R6qH/dP4ffHALBi3KxTPkvwoQ8CmcNVyBkXzRijZX0S6CDJFWge/zla6qdoNdesX qTTV8BTkU6lWpBQKOPuTmUgGnZTnaDtVbzgIAnksVcavroX7/Arfd8CWAnwD1AyM kRu4ydYlClcr4RDT8MjEUaRiQbY40fxqNIHSyH+EinONrFT6NL+X1VPsu6oOVX4K zXmghAYhPYsMcRTn4fwUWy+SWYAyJUYSmbXZS0NI/ZWL0lKc536hYpi4YD/R9xL4 hnpjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=HDza7/683QCkX3H5eWrqv8InSpk2rLdn0mOGd46QI DU=; b=TpKJoLQnibY0eGCfXHH4eOO6KAqp/w34NOsM7vLzByr7qPqi0kRgLnNT3 7aBofBiEpL5g9VxZ4a85lTfurjGf6UGjiluA+R371Zt3ibDx2N8FxfyLdOGrhK4x mw0FEyolmK5f7U5al8az1VstNFOYN+hNTaDLy0NG2COhGS1XIa+z1FzEvnT2V2b7 Q0CTpqxBzh9mWcudRSkeq6muHBL1s1RJVxJZGc1e43zeHAl8DzJrT62uQQ4w3JZ9 uAKrd2kVGpiGMLc4EUhTlIiDsE3dnY91N/vyeOIX2+VTCN/reiOswmqbzhiXD36B QJVxg+G5WCkpkygdJ2yqyujLqrvtg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeiiedgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrg htthgvrhhnpeefudfhgfetgfetvddvffeiuddtkeffgedvjeejtdeiheefgfelfeeutdel vdfggfenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedutdekrdehuddruddtud drleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 5AAE524005D; Thu, 3 Dec 2020 09:26:09 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: <160505658534.5583.16251883250744786928@ietfa.amsl.com> Date: Thu, 3 Dec 2020 09:26:08 -0500 Cc: General Area Review Team , draft-ietf-suit-information-model.all@ietf.org, last-call@ietf.org, suit@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <160505658534.5583.16251883250744786928@ietfa.amsl.com> To: Tim Evens X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Suit] [Gen-art] Genart last call review of draft-ietf-suit-information-model-08 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 14:26:13 -0000 Tim, thanks for your review. I entered a No Objection ballot. Alissa > On Nov 10, 2020, at 8:03 PM, Tim Evens via Datatracker = wrote: >=20 > Reviewer: Tim Evens > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-suit-information-model-?? > Reviewer: Tim Evens > Review Date: 2020-11-10 > IETF LC End Date: 2020-11-11 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Looks good. >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Dec 8 03:55:15 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED873A0C55; Tue, 8 Dec 2020 03:55:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: suit@ietf.org Message-ID: <160742851420.20479.16479689508533089665@ietfa.amsl.com> Date: Tue, 08 Dec 2020 03:55:14 -0800 Archived-At: Subject: [Suit] I-D Action: draft-ietf-suit-manifest-11.txt X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 11:55:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Software Updates for Internet of Things WG of the IETF. Title : A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest Authors : Brendan Moran Hannes Tschofenig Henk Birkholz Koen Zandberg Filename : draft-ietf-suit-manifest-11.txt Pages : 111 Date : 2020-12-08 Abstract: This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an IoT device), where to find the that code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-suit-manifest/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-suit-manifest-11 https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-suit-manifest-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 8 11:16:08 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EBC3A112A; Tue, 8 Dec 2020 11:15:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: housley@vigilsec.com, rdd@cert.org, suit@ietf.org, suit-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160745495790.15596.14173706248476719755@ietfa.amsl.com> Date: Tue, 08 Dec 2020 11:15:57 -0800 Archived-At: Subject: [Suit] suit - New Meeting Session Request for IETF 110 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 19:16:06 -0000 A new meeting session request has just been submitted by Russ Housley, a Chair of the suit working group. --------------------------------------------------------- Working Group Name: Software Updates for Internet of Things Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 80 Conflicts to Avoid: Chair Conflict: ipwave lamps stir teep ipsecme rats sacm Key Participant Conflict: oauth secdispatch saag tls mls acme cfrg ace People who must be present: Russ Housley Dave Thaler Roman Danyliw Hannes Tschofenig David Waltermire Henk Birkholz Brendan Moran Milosch Meriac David Brown Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Dec 17 11:23:47 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7413A0E8C; Thu, 17 Dec 2020 11:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ans20yp5L7m; Thu, 17 Dec 2020 11:23:34 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338403A0E60; Thu, 17 Dec 2020 11:23:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CB1AE389AC; Thu, 17 Dec 2020 14:26:16 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id m9SbiclX722K; Thu, 17 Dec 2020 14:26:16 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 17199389A8; Thu, 17 Dec 2020 14:26:16 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5217E11B4; Thu, 17 Dec 2020 14:23:30 -0500 (EST) From: Michael Richardson to: mud@ietf.org, opsawg@ietf.org, iotops@ietf.org, suit@ietf.org In-Reply-To: <27659.1608229409@localhost> References: <27659.1608229409@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Suit] Manufacturer Usage Description for quarantined access to firmware - draft-richardson-shg-mud-quarantined-access-02 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 19:23:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > 5) Manufacturer Usage Description for quarantined access to firmware > draft-richardson-shg-mud-quarantined-access-02 [perhaps I should rename it with opsawg in the filename] > Abstract > The Manufacturer Usage Description is a tool to describe the limited > access that a single function device such as an Internet of Things > device might need. This is a small extension to RFC8520 which provides a new attribute to each ACL. It marks the ACL as being essential for firmware/software updates. In the parlance of draft-kuehlewind-update-tag-03 this document is an Exte= nds. The need for this extension became obvious during the PoC phase of the CIRA SecureHomeGateway back in 2018. We put a sample device into the deny list, kicking the device off the Internet, and and then wondered... so now what? How does it get updated? Is it landfill? There must be a better way. I believe that this work needs to be adopted by OPSAWG to be able to make p= rogress. I presented it at the spring IETF107 meeting in OPSAWG, but it is quite likely that are some Software Update people who haven't seen it. The slides are at: https://datatracker.ietf.org/meeting/interim-2020-opsawg-01/materials/s= lides-interim-2020-opsawg-01-sessa-device-quarantine-definition-for-manufac= turer-usage-descriptions-rfc8520-00 or: https://github.com/CIRALabs/shg-mud-quarantine/tree/master/presentations At present, the document isn't much more than a YANG modules with a lot of words in it! (Much like a third of the documents coming from the RTG area) The security considerations will need some work beyond "TBD": there are two= obvious concerns: 1) did a third party lie about what they essential connections are? This boils down to: how did the MUD controller establish trust in the MUD file in the first place. I have another document about that. 2) was did the manufacturer lazy and just marked everything as essential? Or, how can we be sure what's essential anyway? What kind of local policy might need to override this anyway, and does that render this all moot? In the two years since I started this document SUIT has made significant pr= ogress. One thing that the CIRA SHG team really wanted was to actually collect the firmware ourselves. That is, rather than allowing the device out to the network to get it's own firmware, we would have rather been able to discove= ry the URL of the new firmware using a standard protocol, cached it locally, a= nd then pointed the device at that copy. This would essentially have rendered the two concerns above irrelevant. SUIT has intentionally not standardized such a mechanism as being too much = of a bikeshed/rathole (I think), but I am interested if there is some interest in doing that. Perhaps in addition to this document, or maybe, instead of. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/bsDIACgkQgItw+93Q 3WXIegf/TVZcx9NkRXRuGulQ4U4EvZcn+PgYO1erpM+XCsYsgW5E6zz//3iag70I RQ/gh2ZYdiZtHQ5p00nFdv0OQ4QjgRmadz7FdNbiI0GuOKeR05jaQ/G+k+N4phhX ODqtTO5oAs2vXCAUDRlHFItrwAOCERunclULTzsP6NXJY61VdZXexc92/Jl9y3Ev QTp1eMvp8P/yUgeoEnvyPwEhx2vwpQob6ef86n0HJ9bjU5gecqNmXDmFh4L3nKyl /0vM7+FUtXEzE/C/ofAhQr0jCqxR5wUo0buzj4HYCrU/0Mm5czEaWhk3cNyTzmam Nk9sqnhP88mKHNeAWI6fch11j1j5TA== =/qtm -----END PGP SIGNATURE----- --=-=-=--