Re: [IPsec] [Lwip] Paul Wouters' Discuss on draft-ietf-lwig-minimal-esp-08: (with DISCUSS and COMMENT)

[Daniel Migault <[e-mail]>]

Hi all,

My reading of the datatracker is that the document in IESG Evaluation::AD
Followup for 117 days. I do not see any follow-up with the following email
from may 25 with the latest changes and believe all concerns have been
addressed. I am wondering what prevents the document from being sent to the
RFC queue and if there is anything expected from my side.

Yours,
Daniel


On Mon, Apr 25, 2022 at 2:19 PM Daniel Migault <[e-mail]> wrote:

> Hi Paul,
>
> Please find my response to your comments. The current version of the file
> integrates the language changes as well as changes to address the concerns
> of this thread:
>
>
> https://github.com/mglt/draft-mglt-lwig-minimal-esp/commit/d7710c19802bdce4c978d71ad303b739e1406f1e
>
> Yours,
> Daniel
>
> On Tue, Apr 12, 2022 at 5:10 PM Paul Wouters <[e-mail]>
> wrote:
>
>>
>> On Tue, Apr 5, 2022 at 10:09 PM Daniel Migault <[e-mail]>
>> wrote:
>>
>>> Hi Paul,
>>>
>>> Thanks for commenting. Please find my responses below.
>>>
>>> Section 2:
>>>
>>>>
>>>> It suggests a partial SPI match can be used, based on the assumption
>>>> that
>>>> the SPI number is known to have mostly zeros because the device only
>>>> uses
>>>> a hardcoded limited set (eg 257 to 260). While this is true for the
>>>> outbound
>>>> SPI, this may not be true for the inbound SPI, especially if the peer
>>>> is not
>>>> a "minimal ESP" device but a regular multipurpose OS. I think some
>>>> clarification
>>>> is needed for this minimum implementation optimization.
>>>>
>>>>
>>> I probably missed the comment. I understand that a partial SPI match
>>> would mean that only a subset of bytes will be considered, but I cannot
>>> find text that suggests it. I do not also see any mention of special values
>>> for the SPI. I also understand from the comment that the text is suggesting
>>> some SPI values but I cannot find what text suggests it - at least for a
>>> very small subset.
>>>
>>
>> This was based on:
>>
>>     The index may be based on
>>     the full 32 bits of SPI or a subset of these bits.
>>
>>
>> If you index it on a partial length, you need to have generated these as well with reduced length or else this operation would not provide unique indexes.
>>
>> And you are not generating the peer's SPI, so those indexes need to use the full 32 bit too.
>>
>> Perhaps you mean to say that for indexing your own generated SPIs, you might know you only need to look at a subset of bytes?
>>
>> Perhaps you can clarify the indexing sentence ?
>>
>> The SPI field (4 bytes) is decoupled between the SPI value (3 bytes) and
> a rekey index (1 byte).
>
> Here is the text that I believe addresses your concern:
> """
>  Alternatively, some constrained devices will not implement IKEv2 or
> Minimal IKEv2 and as such will not be able to manage a roll-over between
> two distinct SAs. In addition, some of these constrained devices are also
> likely to have a limited number of SAs - likely to be indexed over 3
> bytes only for example. One possible way to enable a rekey mechanism with
> these devices is to use the SPI where for example the first 3 bytes
> designates the SA while the remaining byte indicates a rekey index.
>
> SPI numbers can be used to implement tracking the inbound SAs when
> rekeying is taking place. When rekeying a SPI, the new SPI could use the
> SPI bytes to indicate the rekeying index.
> """
>
>>
>>
>>> [2]
>>>>
>>>> Section 2.1:
>>>>
>>>>        SPI that are not randomly generated over 32 bits may lead to
>>>> privacy
>>>>        and security concerns.
>>>>
>>>> The "may lead to security concerns" would be something that at the very
>>>> least needs
>>>> to be understood and specified in the Security Considerations section.
>>>> If it is too
>>>> difficult to determine the concerns, perhaps this optimization should
>>>> be removed from
>>>> the draft.
>>>>
>>>
>>>
>>>>
>>>>        As a result, the use of alternative designs requires careful
>>>> security
>>>>        and privacy reviews.
>>>>
>>>> If it is known this proposal requires careful security reviews, were
>>>> these done? If
>>>> so, why not replace this warning of danger with the actual output of
>>>> those reviews?
>>>> If reviews were not done, it would imply this document hasn't fully
>>>> worked out its
>>>> Security Considerations.
>>>>
>>>
>>> The concerns are explicitly mentioned in this section with what needs to
>>> be considered.
>>>
>>
>> This is mostly a language problem then. When a document states " the use
>> of alternative designs requires careful security and privacy reviews",
>> it implies the reader needs to do these themselves and these were not
>> part of the document. I had given some language improvement suggestions
>> separately that might cover this? If not, please clarify this issue.
>>
>> current text is:
>
> """
>  As a result, the use of alternative designs requires careful security
> and privacy reviews.
> """
>
>
>
>> [3]
>>>>
>>>>        SPI can typically be used to implement a key update
>>>>
>>>> What is a "key update" in this context? It seems this section is
>>>> suggesting to use
>>>> part of the SPI octet space to signal things to another part of the
>>>> code on the device?
>>>> If so, would that code part then clear out those overloaded SPI octets
>>>> or would they go
>>>> (unencrypted!) over the network for everyone to see?
>>>>
>>>> The text says:
>>> """
>>> SPI can typically be used to implement a key update with the SPI
>>> indicating the key is being used.
>>> For example, a SPI might be encoded with the Security Association
>>> Database (SAD) entry on a subset of bytes (for example 3 bytes), while
>>> the remaining byte indicates the rekey index.
>>> """
>>>
>>> The last byte of the SPI indicates the key index and as the SPI is
>>> unencryted.
>>>
>>
>> I know what the text says, but that text is not clear. Please clarify or
>> expand what "key update" is.
>>
>
> The text here seems clearer:
> """
>  Alternatively, some constrained devices will not implement IKEv2 or
> Minimal IKEv2 and as such will not be able to manage a roll-over between
> two distinct SAs. In addition, some of these constrained devices are also
> likely to have a limited number of SAs - likely to be indexed over 3
> bytes only for example. One possible way to enable a rekey mechanism with
> these devices is to use the SPI where for example the first 3 bytes
> designates the SA while the remaining byte indicates a rekey index.
>
> SPI numbers can be used to implement tracking the inbound SAs when
> rekeying is taking place. When rekeying a SPI, the new SPI could use the
> SPI bytes to indicate the rekeying index.
> """
>
>>
>>
>>>
>>>
>>>> [4]
>>>>
>>>>        While the use of randomly generated SPIs may reduce the leakage
>>>> or
>>>>        privacy of security related information by ESP itself, these
>>>>        information may also be leaked otherwise.
>>>>
>>>> This is not a strong argument. This sentence and the entire paragraph
>>>> really seem to
>>>> want to say something like "if you can see the network packets, the
>>>> information
>>>> leak would already be present by seeing the encrypted traffic,
>>>> irrespective of
>>>> whether the SPI is truly random or selected in a way that identifies
>>>> the manufacturer"
>>>>
>>>>
>>> The text says random SPI does not guarantee privacy sensitive
>>> information is not leaked.
>>>
>>
>> That sentence (and the entire paragraph) don't really make any concrete
>> good statement. I tried to paraphrase a better one above. If you think I
>> misinterpreted your words,
>> please provide a clearer text for the draft.
>>
>
>  I think the text has been removed.
>
>>
>>
>>>
>>>
>>>> [5]
>>>>
>>>>        The security of all data
>>>>        protected under a given key decreases slightly with each message
>>>>
>>>> I do not know of a generic claim like this for ESP. Can a reference be
>>>> provided?
>>>>
>>>
>>> It seems like a generic property for cryptographic keys. Quoting the
>>> security consideration of RFC4106:
>>> """
>>>
>>> The other consideration is that, as with any encryption mode,
>>>
>>> the security of all data protected under a given security
>>>
>>> association decreases slightly with each message.
>>>
>>> """
>>>
>>>
>> Ok, it is a bit of an open door, and not really information that an
>> implementer can do anything with, but consider this issue resolved.
>>
>>
>> In general, rekeying is done to avoid decrypting previous traffic in case
>>>> of a key compromise.
>>>> Or perhaps you mean the limits of algorithms like AES_CBC (or 3DES)
>>>> with respect to
>>>> birthday and collision attacks? eg the commonly used maximum of 2^32-1
>>>> crypto operations
>>>> (which is not the same as maximum packets)
>>>>
>>>> In these cases, the SN is only relevant for very high speed links, eg
>>>> gbps and would never
>>>> apply to an IoT device that requires minimal ESP.
>>>>
>>>
>>> There is also the case, where an IoT device is provisioned with a
>>> lifetime key in which case the key will be used as long as the device is
>>> alive. This addresses a comment from Nancy as far as I remember and I agree
>>> with her.
>>>
>>
>> If you send 1 packet per second, and use the SN to represents seconds
>> since SA established, you have 136 years for your constrained device.
>> Anyway, this discussion does not matter as it was just my text trying to
>> explain the previous item, which I said can be considered resolved.
>>
>>
>
>>
>>
>>>
>>>> [6]
>>>>
>>>> As noted in the TSVART review:
>>>>
>>>>        Also, for devices that spend significant time sleeping, the SN
>>>>        would jump hugely on first waking. That shouldn't require any
>>>>        larger window (unless a stale packet from prior to the sleep was
>>>>        only released after a new packet on waking). But the receiver
>>>>        would need to be able to somehow detect massive jumps in the high
>>>>        order bits that are not communicated in the SN field.
>>>>
>>>> Perhaps the document can add more specific detail on how to use the
>>>> commonly
>>>> implemented time values into valid SNs that avoid ESN issues ?
>>>>
>>>>
>>>> The implementation itself will depend on the application - especially
>>> if other mechanisms than those implemented by the incrementation counter
>>> are needed. Maybe you can let me know what additional text you expect ?
>>>
>>
>> Think of an implementer that is not aware of what application will run on
>> this constrained device with IPsec stack. How should they implement SN's?
>> That is the advise that is missing in this document.
>>
>
> I added:
> """
> The RECOMMENDED way for multipurpose ESP implementation is to increment a
> counter for
> each packet sent.
> """
>
>>
>>
>>> """
>>> Of course, one should only consider use of a clock to generate SNs if
>>> the application will inherently ensure that no two packets with a given SA
>>> are 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 difference may result in the packet out of the
>>> receiver's windows and that packet being discarded.
>>> """
>>>
>>
>> While this is a slight hint to an implementer, it is not enough for them.
>> Why not give them better advise?
>>
>
> This seems heavily dependent on the application. What stronger advice
> would you have in mind ?
>
>>
>> [7]
>>>>
>>>>        so the constrained device may not proceed to such checks
>>>>
>>>> The language issue here inverts the meaning. What is meant is "so the
>>>> constrained device
>>>> may omit such checks"
>>>>
>>>
>>>  I agreed and changed it.
>>>
>>
>> Resolved.
>>
>>
>>>
>>>> [8]
>>>>
>>>>        TFC has not yet being widely adopted for standard ESP traffic.
>>>>
>>>> It is widely implemented (eg in Linux). I agree that using it seems
>>>> rare.
>>>> I am not convinced the reason for this is as is written. The issue I
>>>> think
>>>> more relates to deciding to what size to pad. The easiest is to use the
>>>> MTU,
>>>> but due to various encapsulation techniques (ESPinUDP, PPP-OE) it is
>>>> not always
>>>> clear what the MTU of the IPsec link is. And path MTU discovery with
>>>> IPsec does
>>>> not really work in practice.
>>>>
>>>
>> Note that by comment was regarding the "adopted". This can be interpreted
>> as "implemented" or "used".
>> Perhaps just change adopted to deployed? And change "not yet" as I
>> presume you have no expection
>> for this to change in the future ?
>>
>
> I added your suggestion:
>
> """
> TFC has been widely implemented but it is not widely deployed for ESP
> traffic.
> """
>
>>
>>
>>>
>>>> But if the application/device tends to send packets between 1 and say
>>>> 125 bytes,
>>>> it could always pad to 125 to not leak any information by packet size.
>>>> The question
>>>> on when to do this or not really depends on the traffic being
>>>> protected. And if this
>>>> the case, then it might be best to let the IKEv2 negotiation determine
>>>> whether or not
>>>> to use this - just like regular use of TFC.
>>>>
>>>> Regardless, TFC is optional and a minimum implementation can just omit
>>>> it. Since
>>>> this document would also be combined with efforts reducing sending
>>>> bytes to
>>>> preserve energy, it would make sense to avoid using TFC padding.
>>>> Especially for sensors
>>>> that for example just always send a one byte temperature value to begin
>>>> with.
>>>>
>>>>        Such information could be used by the attacker in case a
>>>> vulnerability is
>>>>        disclosed on the specific device.
>>>>
>>>> I don't think "vulnerability" here is the issue. It could lead to
>>>> exposing the size
>>>> of the original packet being protected by IPsec, which could (or could
>>>> not) leak
>>>> information to an observer on the network.
>>>>
>>>
>>> What I meant is that traffic shaping can be used to identify the device,
>>> which could be useful when such a device is known to be vulnerable.
>>> The vulnerability comes after traffic shaping has been performed (see also
>>> first section).
>>>
>>
>> Then just omit the "in case a vulnerability is disclosed". Just say the
>> information could be used.
>>
>> Separate note, I personally find "traffic shaping" a confusing term as it
>> seems to be used for different things.
>>
>>  I believe that providing an example on how the information can be used
> is rather clarifying. The current text says:
> """
> Such information can be used, for example, by an attacker in case a
> vulnerability is known for the specific device or application.
> """
> traffic shaping has been removed.
>
>
>>
>>>
>>>> [9]
>>>>
>>>>        a minimal ESP implementation may not generate such dummy packet.
>>>>
>>>> I think what is meant is "MUST NOT generate".
>>>>
>>>
>>> MUST NOT requires RFC4303 to be updated and is probably too strong. I
>>> have been asked to remove all normative text.
>>>
>>
>> change "may not" to "may simple choose to never generate"
>>
>>
> We have the text you proposed:
>
> """
> An implementation can omit ever generating and sending dummy packets.
> """
>
>> [10]
>>>
>>>>
>>>> The Next Header Section is better named Dummy Packet. While it
>>>> discusses the mandatory
>>>> Next Header field, it really only states not to send Dummy Packets. But
>>>> it almost reads
>>>> as if the Next Header can be ignored or omitted.
>>>>
>>>>
>>> This requires changing ESP and the text actually requires the Next
>>> Header field to be read.
>>> """
>>> For interoperability, a minimal ESP implementation must discard dummy
>>> packets without indicating an error.
>>> """
>>>
>>
>> I am not asking you to rename a term from RFC 4303. I am asking you to
>> rename the section, as the section is
>> really about the Next Header field value 59 only. (I did so in the
>> language changes I sent you separately)
>>
>>
> I took your wording.
>
>> [11]
>>>>
>>>>        4.  Avoid Padding by sending payload data which are aligned to
>>>>            the cipher block length - 2 for the ESP trailer.
>>>>
>>>> Isn't this advise just moving the padding from the IPsec layer to the
>>>> application
>>>> layer? Eg the packet size or energy use would not be different if one
>>>> implements
>>>> this advise?
>>>>
>>>
>>> You are correct, sending padding versus application bytes does not
>>> change power consumption. However, not sending padding bytes ensures you
>>> only carry application information - and as such do not have an extra radio
>>> frame to carry a padding.
>>>
>>
>> but if "only application data" includes "padded application data", then
>> there would not be an extra radio frame? The block cipher size needs to be
>> a certain size. If there is not enough
>> application data, it is padded to make it so. If an application needs to
>> send 14 bytes, I don't think it matters that it will add 2 dummy bytes at
>> the application layer to "avoid padding" in
>> the IPsec code. And what is send over the wire is the same regardless the
>> solution, the 16 byte block size ?
>>
>> Perhaps rephrase this to say the application should attempt to avoid
>> sending a number of bytes that is just over the blocksize, but then again
>> that advise is kind of odd too, since
>> the application should just not send more data than needed. Eg it could
>> use compression if that would be more energy efficient than sending more
>> radio frames. And that advise
>> is already true for everything the application does, irrespective of
>> IPsec. So the question remains, what is this statement trying to accomplish
>> for a minimum ESP implementer to do?
>>
>>  The intention is to recommend maximizing the information bits sent, when
> padding represent no additional information. In that sense CBC is likely
> not to be recommended.
>
>>  [12]
>>
>>>
>>>> Would it be useful to be able to signal a "mininum ESP" via IKEv2? I
>>>> can imagine a simple
>>>> Notify could be used to signal this. A peer receiving this could then
>>>> ensure it is
>>>> behaving in a "minimum ESP" compatible way even if it is a
>>>> multi-purpose OS.
>>>>
>>>>
>>>> No. minimal ESP is compatible with the standard ESP as mentioned in the
>>> abstrct / intro:
>>>
>>
>> Yes, but the other end might use padding or dummy packets and you could
>> tell the other end to please not do that because it still takes energy to
>> receive and process these.
>>
> This seems to change the scope of minimal ESP.... probably good for an
> extra minimal ESP... but as long as IKEv2 is supported, it might support
> also these two features. That said, the removal of padding is probably
> feasible using diet-esp.
>
>>
>>
>>
>>>
>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>>
>>>> There is a bit excessive and inconsistent linking to RFC 4303 throughout
>>>> the document. I think on first use of ESP the RFC can be referenced, but
>>>> further the document can just talk about ESP without keeping links to
>>>> RFC 4303.
>>>> (I also thought there should not be any links in the abstract?)
>>>>
>>>> The document should maybe mention IPsec v3 is meant for "ESP". IPsec v3
>>>> is a superset
>>>> of IPsec v2. There is no compatibility issue because the "new" things
>>>> in v3 are
>>>> all negotiated via IKE.
>>>>
>>>>
>>> The document is limited to ESP RFC4303.
>>>
>>>
>>>> I don't understand "a form of partial sequence integrity", as integrity
>>>> is a boolean - it passes or fails. I don't understand "partial"
>>>>
>>>> "a form of partial sequence integrity" is the abstract of RFC4303 which
>>> defines ESP.
>>>
>>
>>> RFC4303:
>>> """
>>>  ESP is used to provide confidentiality, data origin authentication,
>>> connectionless
>>>    integrity, an anti-replay service (a form of partial sequence
>>>    integrity), and limited traffic flow confidentiality.
>>>  """
>>>
>>
>> In that case I would recommend using "an anti-replay service" without the
>> term in brackets.
>>
>>
>>
>>
>>> "it becomes crucial" is a bit weak. I would say it must be guaranteed
>>>> that ESP on IoT remains interoperable with currently deployed ESP.
>>>>
>>>>        This may raise some privacy issues as an
>>>>        observer is likely to be able to determine the constrained
>>>> devices of
>>>>        the network.
>>>>
>>>> This text might be better placed in a Privacy Considerations section.
>>>>
>>>> Privacy concerned are exposed within the SPI section. Splitting the
>>> section into multiple sections will make the document harder to read.
>>>
>>>
>>>> The term "traffic shaping" is used in the document to refer to traffic
>>>> being
>>>> padded (padding or TFC). Perhaps my personal exposure to Linux has
>>>> caused me
>>>> to think of "traffic shaping" to mean to control the speed or flow of
>>>> traffic,
>>>> and not meaning "modifying traffic size".
>>>>
>>>> Traffic shaping does not mean modifying traffic size.  I see traffic
>>> shaping being used to describe optimization as well inferring activity from
>>> the traffic.
>>>
>>
>> I still advise against using this term, or to define the term as you use
>> it somewhere in the introduction section.
>>
>> Paul
>>
>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson