Re: [Iot-directorate] [Lwip] Iotdir last call review of draft-ietf-lwig-minimal-esp-03

[Daniel Migault <[e-mail]>]

Hi Nancy,

Regarding ISSUE 3, I have the impression that the concern that AES-GCM,
Chacha20-Poly1305 or AES-CCM only send a 64 bit IV which suggest that only
64 bit IV can be sent with ESP.
In fact the IV is not a field in ESP but is defined for each suite, as a
result, ESP would be able to support any suite with larger or short IV.
Then, the use of a 96 bit nonce is not uncommon, actually AES-GCM and
Chacha20-Poly1305 do use 96 bit nonce and AES-CCM uses a 88 bit nonce. The
nonce is formed based on a slat and the IV. Similar construction may be
provided for AES-GCM-SIV if needed as far as I can see.

AES-GCM-SIV is only defined as an algorithm, I also suggest to add other
alternatives that have a similar goals. The current text is as follows and
I think it might close the ISSUE 3.

When the key is likely to be re-used across reboots, it is RECOMMENDED to
consider algorithms that are nonce misuse resistant such as, for example,
AES-SIV [RFC5297], AES-GCM-SIV [RFC8452] or Deoxys-II [deoxys].
Note however that currently none of them has yet been defined for ESP.

I suspect the ISSUE 1 and ISSUE 2 are related to IV collision. If so it
seems to me related to the  collision of IV. If so I think the current
proposed text for SN addresses the concerns that an algorithm should not be
used beyond its limits. In addition the following text in the security
consideration seems to address that concern as well:

the nodes MUST ensure that keys are not used beyond their lifetime and that
the appropriate use of the key remains across reboots - e.g. conditions on
counters and nonces remains valid.

I suspect that collision is related to the collision of IV which is only a
concern when the IV needs to be unpredictable.  I am tempted to think that
algorithms that the properties of the IV are really part of the algorithm
properties and that they cover / include into the lifetime of the keys. On
the other hand, most recommended algorithms AES-GCM, AES-CCM,
Chacha-Poly1305 are using IVs that just do not need to repeat, and so use
counters where collision is not a concern. Of course this does not concerne
collision across reboot, but I do not think these were the collisions that
caused your concern.  If I am correct, that probably also addresses ISSUEs
1 and ISSUE 2.

I will publish the version with the current changes so reviews have the
most recent editorial changes and will update from that according to your
response. Again thank you for the in depth review and the many comments
that already result in many clarifications - at least I think so.

Yours,
Daniel

On Tue, Mar 30, 2021 at 10:45 PM Daniel Migault <[e-mail]> wrote:

> Hi Nancy,
>
> Thank you very much for your review. Please see inline my responses. I
> believe all concerns raised have been addressed. I also believe the current
> text addresses some concerns also raised by Paul W.
>
> The current version can be found here:
>
> https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393a246298e37adcf2683afa2061a40b4ed89
>
> I think there are however three remaining issues that might get further
> discussions. For all of these I provided a response, but I am unsure it
> really addresses the three concerns below:
>
> ----
> ISSUE 1
> ----
> - 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 :-)
>
> I am missing the concern. I understand the first concern is that the
> current text seems to push the limit of packets being sent being determined
> by the SN as opposed to cryptographic properties. If my understanding is
> correct, I have the current text seems clear that crypto properties are
> given priorities. I suspect more guidance would be given. If that is the
> case, I find it difficult as these guidances are really based on the
> cryptographic algorithm and the key sizes. In any case, if I am
> missing something, feel free to propose some text.
>
> """
> Note that the limit of messages being sent is primarily determined by the
> security associated with the key rather than the SN.
> The security of all data protected under a given key decreases slightly
> with each message and a node MUST ensure the limit is not reached - even
> though the SN would permit it.
> """
>
> I understand the second concern as that current text is read as rekey
> mechanisms are recommended only when there is a risk the SN get exhausted.
> Our intention was to read the text as even if ESN raises the limit to an
> acceptable limit, it is preferred to have a rekey mechanism. I propose the
> following text to clarify the meaning:
>
> OLD:
> In a constrained environment, it is likely that the implementation of a
> rekey mechanism is preferred over the use of ESN.
>
> NEW:
> Estimation of the maximum number of packets to be sent by a node is always
> challenging and as such should be considered cautiously as nodes could be
> online for much more time than expected.
> Even for constrained devices, it is RECOMMENDED to implement some rekey
> mechanisms (see <xref target="sec-security-considerations"/>).
> </mglt>
> ---
> ISSUE 2
> ---
> -
> Resilience to nonce reuse goes to the SN considerations as well (see my
> comments for Section 4).
>
> ---
> ISSUE 3
> ---
>
>> 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?
>
> <mglt>
>
> This is correct that AES-GCM-SIV was not mentioned in RFC8221, and I
> mentioned it as an example. Now, it seems more problematic to have an
> example of a cipher suite that does not work for ESP.
> I am balanced between indicating that its support is not defined with ESP
> so the reader still has a reference to an example of such a cipher suite.
>
> I will raise this issue to the WG, but currently the text is as follows:
>
> """
> When the key is likely to be re-used across reboots, it is RECOMMENDED to
> consider transforms that are nonce misuse
> resistant such as AES-GCM-SIV for example<xref target="RFC8452"/>. Note
> however that AES-GCM-SIV has not yet been defined for ESP.
> """
> </mglt>
>
>>
> Yours,
> Daniel
>
>
>
> On Fri, Mar 26, 2021 at 7:27 PM Nancy Cam-Winget via Datatracker <
> [e-mail]> wrote:
>
>> 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….
>>
>> <mglt>
>
> The purpose of the document is to provide guidance to build a minimal ESP
> implementation that remains interoperable with the RFC4303 ESP. In addition
> to the properties that needs to be met by a minimal ESP implementation, the
> document also provides some guidance on how the properties may be
> implemented while also meeting some constraints of specific environments.
> Here is the text I propose:
>
> OLD:
> This document describes the minimal properties and ESP implementation
> needs to meet.
>
>
> NEW:
> This document describes the minimal properties an ESP implementation needs
> to meet to remain interoperable with RFC4303 ESP.
> In addition, this document also provides a set of options to implement
> these properties under certain constrained environments.
> </mglt>
>
> 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.
>>
>> <mglt>
> Thanks for these comments, that is helpful to clarify this section. While
> SPI do not need to be random this is usually how SPI are generated. As a
> result, using non random values raised a lot of discussions while the use
> of random did not raise any discussions. I think that is the reason the two
> visions have been documented in an unbalanced way.
> I agree that the text could be clearer and much more concise. I have
> restructured the full section exposing what 4303 mentions regarding the
> generation of the SPI, what and whay SPI are generally generated randomly
> as well as why and how non random SPI may be generated.  I have also added
> a section that groups consideration on SPI generation. I hope this is
> clearer now.
>
> NEW:
> RFC4303 does not require the SPI to be randomly generated over 32 bits.
> However, this is the RECOMMENDED way to generate SPIs as it provides some
> privacy benefits and avoids, for example, correlation between ESP
> communications.
> To randomly generate a 32 bit SPI, the node generates a random 32 bit
> value, checks does not fall in the 0-255 range.
> If the SPI has an acceptable value, it is used to index the inbound
> session, otherwise the SPI is re-generated until an acceptable value is
> found.
>
> However, some constrained nodes may be less concerned by the privacy
> properties associated to SPIs randomly generated.
> Examples of such nodes might include sensors looking to reduce their code
> complexity, in which case the use of a predictive function to generate the
> SPI might be preferred over the generation and handling of random values.
> An example of such predictable function may consider the combination of a
> fixed value and the memory address of the SAD structure.
> For every incoming packet, the node will be able to point the SAD
> structure directly from the SPI value. This avoids having a separate and
> additional binding between SPI and SAD entries that is involved for every
> incoming packet.
>
> OLD:
>  <t> It is RECOMMENDED to index each inbound session with a SPI randomly
> generate over 32 bits.
> Upon the generation of a SPI the peer checks the SPI is not already used
> and does not fall in the 0-255 range.
> If the SPI has an acceptable value, it is used to index the inbound
> session, otherwise the SPI is re-generated until an acceptable value is
> found.
> A random generation provides a stateless way to generate the SPIs, while
> keeping the probability of collision between SPIs relatively low. </t>
>
> <t> However, for some constrained nodes, generating and handling 32 bit
> random SPI may consume too much resource, in which case SPI can be
> generated using predictable functions or end up in a using a subset of the
> possible values for SPI.
> In fact, the SPI does not necessarily need to be randomly generated.
> A node provisioned with keys by a third party - e.g. that does not
> generate them - and that uses a transform that does not needs random data
> may not have such random generators.
> However, nonrandom SPI and restricting their possible values MAY lead to
> privacy and security concerns.
> As a result, this alternative should be considered for devices that would
> be strongly impacted by the generation of a random SPI and after
> understanding the privacy and security impact of generating nonrandom
> SPI.</t>
> </mglt>
>
> - 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.
>>
>> <mglt>
> If a device of type "A" implements ESP that takes very limited values of
> SPI, an observer that monitors the traffic that observes such values will
> be able to define that there is a high probability the device is of type
> "A". When these devices have vulnerabilities, the observer this information
> may be used by the observer to infer potential vulnerabilities the device
> is subject to. In my mind the observer is an attacker, so I would be
> tempted to consider this as a drawback.
> From your text I have the impression that the use of these non random
> values for SPI may be used by an administrator to monitor potential
> vulnerabilities in its network - which could be seen as a feature. This is
> how I am reading the first sentence of your comment, but I might be missing
> it.
>
> In any case, I agree that this is not the rationale for using non random
> SPIs. In my view that is more a drawback. "In addition" was intended to
> raise an additional security concern which is that knowing the SPI or not
> changing the SPI will ease an attacker to forge packets with a valid SPI. I
> agree with you that this is also associated with any long term ESP sessions
> and can be removed.
>
> As mentioned above, I have restructured and shortened the text and here is
> the content of the "Considerations over SPI generation" section:
>
> NEW:
>
> SPI that are not randomly generated over 32 bits MAY lead to privacy and
> security concerns.
> As a result, the use of alternative designs requires careful security and
> privacy reviews.
> This section provides some considerations upon the adoption of alternative
> designs.
>
>
> Note that SPI value is used only for inbound traffic, as such the SPI
> negotiated with IKEv2 RFC7296 or RFC7815 by a peer, is the value used by
> the remote peer when it sends traffic.
> As SPI is only used for inbound traffic by the peer, this allows each peer
> to manage the set of SPIs used for its inbound traffic.
> Similarly, the privacy concerns associated with the generation of
> nonrandom SPI is also limited to the incoming traffic.
>
> When alternate designs are considered, it is likely that the number of
> possible SPIs will be limited.
> This limit should both consider the number of inbound SAs - possibly per
> IP addresses - as well as the ability for the node to rekey.
> SPI can typically be used to proceed to clean key update and the SPI value
> may be used to indicate which key is being used.
> This can typically be implemented by a SPI being encoded with the Security
> Association Database (SAD) entry on a subset of bytes (for example 3
> bytes), while the remaining byte is left to indicate the rekey index.
>
> The use of a smaller number of SPIs across communications comes with
> privacy and security concerns.
> Typically some specific values or subset of SPI values may reveal the
> models or manufacturer of the node implementing ESP.
> This may raise some privacy issues as an observer is likely to be able to
> determine the constrained devices of the network.
> In some cases, these nodes may host a very limited number of applications
> - typically a single application - in which case the SPI would provide some
> information related to the application of the user.
> In addition, the device or application may be associated with some
> vulnerabilities, in which case specific SPI values may be used by an
> attacker to discover vulnerabilities.
>
> While the use of randomly generated SPI may reduce the leakage or privacy
> or security related information by ESP itself, these information may also
> be leaked otherwise and a privacy analysis should consider at least the
> type of information as well the traffic pattern.
> Typically, temperature sensors, wind sensors, used outdoors do not leak
> privacy sensitive information and most of its traffic is expected to be
> outbound traffic.
> When used indoors, a sensor that reports every minute an encrypted status
> of the door (closed or opened) leaks truly little privacy sensitive
> information outside the local network.
>
>
> </mglt>
>
>> 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.
>
>
>  <mglt>
> The third paragraph says that even if a node knows the other peers does
> not implement antireplay, it must increase the SN.
>
> The 4th paragraphe details one way to increment SN based on time. On a
> sender side, the only constraint is that the SN never repeats, so the
> granularity seems to me that the clock must be that every packet is sent at
> a different time. If I interpret correctly the your comment, I think the
> text below addresses the concern.
>
> """
>  Using time for SN would guarantee a strictly
>    increasing function and avoid storing any additional values or
>    context related to the SN.  When the use of a clock is considered,
>    one should take care that packets associated to a given SA are not
>    sent with the same time value.
> """
>
> Maybe the concern is regarding the synchronization between the sender and
> the receiver. The current text mentions that if the sender uses a clock and
> the receiver considers an incremental counter value, an anti replay
> mechanism is likely to reject the packets.
> I think that we could add text to mention that an anti replay window
> should take into account time derivation of the devices. I think that both
> recommendations should be moved to the receiver paragraph.
> So the concern of the receiver implementing a counter base anti-replay
> mechanism remains in this section but anti replay mechanisms related to SN
> have been moved to the receiving paragraph.
>
> I have also reworded some text in the sendin paragraph, but not changed
> the main structure. Here is the current text:
>
> Usually, SN is generated by incrementing a counter for each packet sent.
> A constraint device may avoid maintaining this context and use another
> source that is known to always increase.
> Typically, constraint nodes using 802.15.4 Time Slotted Channel Hopping
> (TSCH), whose communication is heavily dependent on time, can take
> advantage of their clock to generate the SN.
> A lot of IoT devices are in a sleep state most of the time wake up and are
> only awake to perform a specific operation before going back to sleep.
>
> They do have separate hardware that allows them to wake up after a certain
> timeout, and most likely also timers that start running when the device was
> booted up, so they might have a concept of time with certain granularity.
> This requires to store any information in a stable storage - such as flash
> memory - that can be restored across sleeps.
> Storing information associated with the SA such as SN requires some read
> and writing operation on a stable storage after each packet is sent as
> opposed to SPI or keys that are only written at the creation of the SA.
> Such operations are likely to wear out the flash, and slow down the system
> greatly, as writing to flash is not as fast as reading.
> Their internal clocks/timers might not be very accurate, but they should
> be enough to know that each time they wake up their time is greater than
> what it was last time they woke up.
> Using time for SN would guarantee a strictly increasing function and avoid
> storing any additional values or context related to the SN.
> When the use of a clock is considered, one should take care that packets
> associated to a given SA are not sent with the same time value.
> Note however that standard receivers are generally configured with
> incrementing counters and, if not appropriately configured, the use of a
> significantly larger SN may result in the packet out of the receiver's
> windows and that packet being discarded.
>
> </mglt>
>
>> - 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?
>
> <mglt>
> The intent of the paragraph is to indicate that anti replay is not
> mandatory.
> The paragraph has been slightly updated to clarify the sensor use case
> where implementing anti replay comes with similar issues for a
> constraint device as the use of a counter - that is storing a value in a
> memory for any received packets.
> There are cases where the anti replay mechanism might not be as necessary
> as we may think. We expose some anti replay mechanisms that are based on
> time and mention some considerations to set the window.
> However, we do not provide explicit value as these are expected to be
> dependent on the network or type of application.
> I hope the text exposes in a clearer way the use case of the sensor as
> well as the purpose of the paragraph. Here is the current text:
>
> For inbound traffic, it is RECOMMENDED that any receiver provides
> anti-replay protection, and the size of the window depends on the ability
> of the network to deliver packets out of order.
> As a result, in an environment where out of order packets is not possible
> the window size can be set to one.
> However, while RECOMMENDED, there are no requirements to implement an
> anti-replay protection mechanism implemented by IPsec.
> Similarly to the SN the implementation of anti replay protection may
> require the device to write the received SN for every packet, which may in
> some cases come with the same drawbacks as those exposed for SN.
>
> As a result, some implementations MAY drop an non required anti replay
> protection especially when the necessary resource involved overcomes the
> benefit of the mechanism.
> A typical example might consider an IoT device such as a temperature
> sensor that is sending a temperature every 60 seconds, and that receives an
> acknowledgement from the receiver.
> In such cases, the ability to spoof and replay an acknowledgment is of
> limited interest and may not justify the implementation of an anti replay
> mechanism.
>
> Receiving peers may also implement their own anti-replay mechanism.
> Typically, when the sending peer is using SN based on time, anti-replay
> may be implemented by discarding any packets that present a SN whose value
> is too much in the past.
> Note that such mechanisms may consider clock drifting in various ways in
> addition to acceptable delay induced by the network to avoid the anti
> replay windows rejecting legitimate packets.
> When a packet is received at a regular time interval, some variant of time
> based mechanisms may not even use the value of the SN, but instead only
> consider the receiving time of the packet.
>
> </mglt>
>
>>
>
>> - 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 :-)
>>
>>  <mglt>
> ---
> ISSUE 1
> ---
> I am missing the concern. I understand the first concern is that the
> current text seems to push the limit of packets being sent being determined
> by the SN as opposed to cryptographic properties. If my understanding is
> correct, I have the current text seems clear that crypto properties are
> given priorities. I suspect more guidance would be given. If that is the
> case, I find it difficult as these guidances are really based on the
> cryptographic algorithm and the key sizes. In any case, if I am
> missing something, feel free to propose some text.
>
> """
> Note that the limit of messages being sent is primarily determined by the
> security associated with the key rather than the SN.
> The security of all data protected under a given key decreases slightly
> with each message and a node MUST ensure the limit is not reached - even
> though the SN would permit it.
> """
>
> I understand the second concern as that current text is read as rekey
> mechanisms are recommended only when there is a risk the SN get exhausted.
> Our intention was to read the text as even if ESN raises the limit to an
> acceptable limit, it is preferred to have a rekey mechanism. I propose the
> following text to clarify the meaning:
>
> OLD:
> In a constrained environment, it is likely that the implementation of a
> rekey mechanism is preferred over the use of ESN.
>
> NEW:
> Estimation of the maximum number of packets to be sent by a node is always
> challenging and as such should be considered cautiously as nodes could be
> online for much more time than expected.
> Even for constrained devices, it is RECOMMENDED to implement some rekey
> mechanisms (see <xref target="sec-security-considerations"/>).
> </mglt>
>
>> 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)?
>>
>> <mglt>
> I interpret your concern as if the current document were not mandating the
> padding. My understanding of the section is that we mostly mention how the
> padding should be built and that the format should not be checked by the
> minimal implementation.
> I also believe that the case of AES-CBC has been addressed with the
> following sentence. Feel free however to let me know if I mis-interpreted
> your comment.
>
> """
> The purpose of padding is to respect the 32 bit alignment of ESP or block
> size expected by an encryption transform - such as AES-CBC for example.
> ESP MUST have at least one padding byte Pad Length that indicates the
> padding length.
> """
>
> I think it makes sense to have it as a recommendation, and here is the new
> text:
>
> OLD:
> As such TFC is not
>    expected to be supported by a minimal ESP implementation.
>
> NEW:
> s such it is NOT RECOMMENDED that minimal ESP implementation supports TFC
> """
> </mglt>
>
>
>> 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?
>>
>> <mglt>
> The Next Header is a mandatory field, so the minimal ESP needs to support
> it, which support the ability to remove "no next header packet". I am
> unsure what needs to be added to the text as it specifies:
>
> """
> the Next Header is a mandatory 8 bits field in the packet [...]
> """
> and
> """
> [...] a minimal ESP implementation MUST discard dummy packets.
> """
> I understand that the etxt needed to be more concise. Here are two
> sentences I changed. Let me know if there are other I am missing.
>
>
> OLD:
> Next header is intended to specify the data contained in the payload as
> well as dummy packet, [...]
>
> NEW:
> Next header specifies the data contained in the payload as well as dummy
> packet
>
> OLD:
> it is not expected to be part of a minimal implementation of ESP.
>
> NEW:
> As a result, it SHOULD NOT be part of a minimal implementation of ESP
>
>
> I am a bit reluctant saying that a minimal ESP SHOULD NOT send dummy
> packet as RFC4303 mentions:
>
> """
>
> A transmitter MUST be capable of
>    generating dummy packets marked with this value in the next protocol
>
> """
> </mglt>
>
>> Section 7:
>> - Do you mean authentication only w/no encryption?
>>
>> <mglt>
> considering the previous comments as well, here is the new text I propose:
>
> OLD:
> As detailed in <xref target="sec-encr"/> we recommend using
> authentication, the ICV field is expected to be present that is to say with
> a size different from zero.
> This makes it a mandatory field which size is defined by the security
> recommendations only.
>
> NEW:
> As detailed in RFC8221 authentication or authenticated encryption are
> RECOMMENDED and as such the ICV field MUST be present with a size different
> from zero.
> It length is defined by the security recommendations only.
> </mglt>
>
> 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?
>
> <mglt>
> Yes, I did not want to duplicate the cryptographic recommendations listed
> in RFC8221 - which includes some IoT specific recommendations. I agree that
> the section may be considered as guidelines but it seems ESP is a bit
> decoupled from the cryptography used.
> </mglt>
>
>
>> - Currently, the ciphers that provide confidentiality always
>> include authentication, so not sure the motivation for the last sentence?
>
>  <mglt>
> If the last sentence is
> """
> Recommendations are provided for standard nodes as well as constrained
> nodes.
> """
>
> The intention was to mention that the recommendations do not necessarily
> apply to a constrained environment. I agree it does not appear to be
> essential, so I removed it.
>
> </mglt>
>
>> -
>> Resilience to nonce reuse goes to the SN considerations as well (see my
>> comments for Section 4).
>
> <mglt>
> ----
> ISSUE 2
> ---
> I think I misunderstood your comment in both places so I leave it open.
> </mglt>
>
>> 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).
>>
> <mglt>
> Though we do not mention "pre-shared" keys, I am wondering if the text in
> the security consideration does not address your purpose:
>
> """
> <t>It is RECOMMENDED to use ESP in conjunction of key management protocols
> such as for example IKEv2 <xref target="RFC7296"/> or minimal IKEv2 <xref
> target="RFC7815"/>.
> Such mechanisms are responsible to negotiate fresh session keys as well as
> prevent a session key being use beyond its lifetime.
>
> When such mechanisms cannot be implemented and the session key is, for
> example, provisioned, the nodes MUST ensure that keys are not used beyond
> their lifetime and that the appropriated use of the key remains across
> reboots - e.g. conditions on counters and nonces remains valid.
> </t>
> """
> </mglt>
>
>> 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?
>
> <mglt>
> ---
> ISSUE 3
> ---
> This is correct that AES-GCM-SIV was not mentioned in RFC8221, and I
> mentioned it as an example. Now, it seems more problematic to have an
> example of a cipher suite that does not work for ESP.
> I am balanced between indicating that its support is not defined with ESP
> so the reader still has a reference to an example of such a cipher suite.
>
> I will raise this issue to the WG, but currently the text is as follows:
>
> """
> When the key is likely to be re-used across reboots, it is RECOMMENDED to
> consider transforms that are nonce misuse
> resistant such as AES-GCM-SIV for example<xref target="RFC8452"/>. Note
> however that AES-GCM-SIV has not yet been defined for ESP.
> """
> </mglt>
>
>> - 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?
>
> <mglt>
> It is more that what the other nodes supports needs to be considered in
> the selection of the cipher suite. While RFC 8221 ensures smooth
> transition, contrainted devices have less interoperability requirements.
> </mglt>
>
>
>> - 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?
>>
>> <mglt>
> yes.
> </mglt>
>
>> Nits:
>> General throughout the draft:   “constraint devices” should be
>> “constrained
>> devices”.
>>
>> <mglt>
> thanks. I changed them all.
> </mglt>
>
>> Abstract:
>>  - Last sentence of first paragraph first clause is awkward “Constrains
>> include
>>  among other limiting….”
>> Perhaps you mean “Some constraints include limiting the…”
>>
> <mglt>
> done. thanks.
> </mglt>
>
>>  - 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).
>>
> <mglt>
> I agree. done.
> </mglt>
>
>>  - 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.
>>
>> <mglt>
> done. thanks
> </mglt>
>
>> 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”
>>
>> <mglt>
> done. thanks.
> </mglt>
>
>>
>>
>> _______________________________________________
>> Lwip mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lwip
>>
>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson