[Lwip] Iotdir last call review of draft-ietf-lwig-minimal-esp-03

[Nancy Cam-Winget via Datatracker <[e-mail]>]

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”