Reviewer: Nancy Cam-Winget Review result: Ready with Issues General Comments The document flows relatively well; I expect that the editors will fix editorial/grammatical issues and I’ve noted a couple below. I did have some questions to some of the descriptions where I expected guidance but read the text as being more considerations so asked questions for clarification. Technical comments: Section 2: - The first paragraph speaks to other drafts defining minimal exchanges/operations and compression to serve IoT; and then states “This document describes the minimal properties and ESP implementation needs to meet.” Needs more clarification, is it so that it can interoperate with non-minimal ESP (e.g. RFC 4303 as defined) or to Interoperate given a set of constraints e.g. the minimal set to be defined in this document including RFC 7815, et al? I think it is the former but the flow of the paragraph makes it unclear…. Section 3: - Why is it RECOMMENDED to have a randomly generated SPI? The next paragraph claims that it is not necessary, which in reading RFC 4303 is the case. So this statement seems to contradict The following paragraph that relaxes this constraint. But the rationale doesn’t seem to coincide; e.g. “A node provisioned with keys by a third party ….uses a transform that doesn’t not needs random data…” Isn’t relevant to the SPI which is intended to be an Index….so better clarification of the security concerns are required. Perhaps on the relaxation, inclusion of consideration of non-reuse and uniqueness of the SPI to reduce replay and maybe cross SA attacks should also be included. - The last paragraph goes to the consideration that constrained devices may suffer from long lag times Between breach-patch availability to actual deployment (or lack thereof). But that rationale, imho, Is not the motivation for predictable SPIs; unless the consideration is more that if they don’t adhere to Appropriate key refreshes and SPI rotation that could lead to replay attacks. On the privacy front, Predictability of SPIs in particular SAs could over time help an attacker gain more information about The actual devices and behavior. Section 4: - The third/fourth paragraph speaks to the potential use of a clock for the sequence counter, which if using an absolute clock with sufficiently fine granularity could maybe work. But stronger language to that granularity is required, the example lists one where periodicity “may be” every 60sec, but there are many devices who will have millisecond (or finer?) granularity….so stronger caution and care descriptions are required. - The considerations for a receiver seems lengthy and am not sure of the point being stressed, other than to RECOMMEND the use of anti-replay protection. I expected a description for the need of a replay window and the window being set to discriminate to the worst case scenario (e.g. if on a wireless noisy medium where there is packet loss, then there may be a say 10ms loss/retry window). I am not understanding the example of the temperature sensor and the relevance to the SN. More concerning to me is the last sentence: “A node MAY drop anti-replay …..instead implant its own internal mechanism”? Is the intent to say if the receiver has a different algorithm independent of the use of SN, then it MAY choose that over the use of SN? - I might challenge due to potential collision attacks that at most, 2^32-1 packets may be sent before the SPI *must* rekey, so the SN and how it is used is part of the security context for the SPI/SA. I might also challenge that a recommendation for using a rekey mechanism is warranted because constrained devices tend to stay up for very, very, very long periods of time and even with an ESN there can be exhaustion :-) Section 5: - If a constrained device does use AES-CBC then padding may be needed, shouldn’t that be considered here? That is, it seems that padding is dependent on the cipher negotiated, right? - “TFC cannot be enable with minimal ESP” seems subjective, given that this is the guidelines perhaps it is a SHOULD NOT (or NOT RECOMMENDED)? Section 6: - More concise language/guidance on minimal ESP is required, e.g. “it is not expected to be part of minimal” needs to be stronger. So, Next Header is mandatory, so guidance is that the field is there…..but is the recommendation for “minimal ESP” be that it can ignore the field? Section 7: - Do you mean authentication only w/no encryption? Section 8: This section starts with eluding that guidelines for cipher selection criteria are provided, but as I read the list they are more considerations than they are guidelines? - Currently, the ciphers that provide confidentiality always include authentication, so not sure the motivation for the last sentence? - Resilience to nonce reuse goes to the SN considerations as well (see my comments for Section 4). Another recommendation here is to also suggest that the provisioned key (and key should be clarified as “pre-shared key”) should also be updated with some regularity to address this issue (as in the rekey mechanism could lie in the management plane that provisions these keys). Currently RFC8452 is not cited as negotiated ciphers in RFC 8221, so considerations for 96bit nonce which doesn’t fit into the ESP header, so while a general alternative not sure how you would apply it to ESP unless changes are made? - What is the point driven in “interoperability”? Is it that constrained devices may have limited interoperability given that they may not support all ciphers in RFC 8221? - Similarly, for the power consumption and cipher suite complexity; is the point that ciphers are chosen based on the constraints (physical, computational and memory) of the device? Nits: General throughout the draft: “constraint devices” should be “constrained devices”. Abstract: - Last sentence of first paragraph first clause is awkward “Constrains include among other limiting….” Perhaps you mean “Some constraints include limiting the…” - Some qualification of “what is required from RFC 4303” is required…. Perhaps you mean “the minimally required set of functions and states from RFC 4303 to achieve compliance and interoperability”? My suggestion may be to just remove this 2nd paragraph as its covered in the 3rd (though I think noting interoperability should be there too). - I would think that there would be a strong issue if there are conflicts with RFC 4303?! So would suggest to remove that sentence or Only that the RFC 4303 remains the authoritative spec to detail full details of ESP. Section 2: - “constraint devices” should be “constrained devices” Section 8: - For “Security”, suggest…”The chosen encryption algorithm MUST NOT be known to be vulnerable or weak” -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
