Ballot for draft-ietf-iotops-7228bis
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Section 3.3: - Please define what 'keeping secrets shielded' means (none of the RFCs listed in Security Considerations mentions this concept). - What (precisely) is 'secure enclave functionality'? - In addition, the levels of 'no', 'some', and 'perfect' are under-specified. In addition, one hardly ever/never refers to security levels as 'perfect', I would argue that it will never be achievable, which begs the question, why specify the level? It actually might be easier to merely remove the section. Section 8: If Section 3.3 remains in the draft, at least add some information here about what vulnerabilities 'keeping secrets shielded' protects against.
Thanks to Shawn Emery for their secdir review.
Thank you for the work that has been put into this document. Please find below one blocking DISCUSS point (easy to address or help me understand), and some non-blocking COMMENT points/nits. As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. I hope that this review helps to improve the document. ## I'd like to understand the basis and safety of class S19 defined in Section 5.1: Can you expand the descriptions to provide counter examples of this support in Constrained-Node Networks, because I doubt that class S19, defining a frame size ≥ 65536 is actually realistic and safe. If these links support the IP service with this size of frames what are the requirements would be needed? I'd like to understand the types of physical-layer error detection methods and synchronisation that can be used to safely deploy such an approach for an IP service. For example, I am also curious about how such large frames would be multiplexed with any other packets at transmission rates expected of Constrained-Node Networks, to avoid long periods of head-of-line blocking. As a possibly simpler alternative (if this could be acceptable), is it possible this document would still be useful without the class S19 entry in the table?
Thanks for providing this informational document to define these reference terms. I have some COMMENTS (non-blocking). These I think are easy to fix by choosing appropriate words: ## In the following: "with elaborate network stacks" I do not have a clear picture of what constitutues an "elaborate" stack, rather than one that is sophisticated, or something else. Is there a better choice of words? ## In the following: "elaborate sleep modes" - similarly I wonder if another word would be clearer? ## The term: "extreme measures" - I hope an IETF RFC could find a better word that "extreme" to describe sophisticated power saving.. ## I stumbled at: "and above often create islands of higher MTU in an otherwise Ethernet-inspired Layer 2 network." - Is it possible to rephrase this, because Ethernet is not universally constrained and the clause does not really explain that typical frames are limited by common Ethernet MTU sizes? ## The words: "he relative increase in energy expenditure during reattachment may be acceptable" lead me to ask acceptable for whom? - I presume this might fall within the power budget, but some refinement in teh words would be helpful. Thanks to Marcus Ihlar for his helpsful IETF Last Call Review submitted for his Transport Area Review Team, and for the resolutions proposed in -08. Best wishes, Gorry
I have no objection for publication of this document as Informational. Many thanks to Valery Smyslov for the ARTART review.
Thanks for the work done in this document. Some comments though: 1) the document use "*small* device" while the constraints are not always linked to the physical size (e.g., deepspace sensors), so suggest to simply use "device" (albeit it does not cover virtual devices) 2) about the 'limited bandwidth', should IoT also cover 'intermittent connectivity' ? (mainly in sections 1 and 2.1) 3) suggest expanded LLN also in the section title 4) I find section 3.3 *VERY UNSPECIFIED* for a BCP. I am trusting the Security AD whether this is 'enough'.
** Section 3.3
3.3. Shielded Secrets
Some platforms can keep secrets shielded (usually in conjunction with
secure enclave functionality). Refer to Table 4 for more details.
Note that Sh9 is aspirational language; no real hardware can achieve
this.
+======+================================+
| Name | Secret shielding functionality |
+======+================================+
| Sh0 | no secret shielding |
+------+--------------------------------+
| Sh1 | some secret shielding |
+------+--------------------------------+
| Sh9 | perfect secret shielding |
+------+--------------------------------+
Is there any narrative text that can be added to describe what these qualitative categories mean. A few examples:
-- what is “secret shielding”? For example: Is this a hardware or software function/only hardware? Would putting a sticker over screws of a chassis qualify as “some secret shielding” or “no secret shielding”?
-- Is the scale here “no shielding” (Sh0) vs. something more than nothing but less that the unachievable perfection (Sh1) vs. “something that doesn’t exist” (Sh9)? If Sh9 us not attainable, isn’t this really a two-scale list of “nothing” vs. “more than nothing”?
-- Against what class of threat is “perfect secret shielding” protecting against?
-- Given the qualitative definitions, one risks different reviewers assessing a given hardware item in different ways. It is unclear if this is a problem for the intended use of this terminology.