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:
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 :-)
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.
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"/>).
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).
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.
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
Daniel
On Fri, Mar 26, 2021 at 7:27 PM Nancy Cam-Winget via Datatracker <noreply@xxxxxxxx> 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.
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. 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.
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.
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.
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.
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.
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.
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"/>).
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.
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.
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.
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.
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>
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.
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
Lwip@xxxxxxxx
https://www.ietf.org/mailman/listinfo/lwip
Daniel Migault
Ericsson
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
