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

From: Paul Wouters via Datatracker <[email-masked]>
Date: Tue, 05 Apr 2022 15:08:07 -0700

Paul Wouters has entered the following ballot position for
draft-ietf-lwig-minimal-esp-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I must apologize first to the authors. Many months ago I promised to send
a diff with language improvements, and I did not do so. Unfortunately, I do
think the document needs this and the amount is too much to leave on the RFC
Editor. I will send a separate diff for language improvements to the authors
and not further comment on language in my ballot here.

[1]

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.

[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.

[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?

[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"

[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?
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.

[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 ?

[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"

[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.

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.

[9]

       a minimal ESP implementation may not generate such dummy packet.

I think what is meant is "MUST NOT generate".

[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.

[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?

[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.

----------------------------------------------------------------------
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.

I don't understand "a form of partial sequence integrity", as integrity
is a boolean - it passes or fails. I don't understand "partial"

"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.

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".

---

From: Daniel Migault <[email-masked]>
Date: Tue, 5 Apr 2022 22:09:19 -0400

Hi Paul,

Thanks for commenting. Please find my responses below.

Yours,
Daniel

On Tue, Apr 5, 2022 at 6:08 PM Paul Wouters via Datatracker <
[email-masked]> wrote:

> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
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.

> If reviews were not done, it would imply this document hasn't fully worked

The concerns are explicitly mentioned in this section with what needs to be
considered.

"""
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 constrain ed 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 SPIs may reduce the leakage or privacy
of security related information by ESP itself, these pieces of information
may also be leaked otherwise.
As a result, a privacy analysis should consider at least the type of
information as well the traffic pattern before determining a non random SPI
can be used.
Typically, temperature sensors, wind sensors, used outdoors may 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) may leak truly little privacy sensitive
information outside the local network.
In both cases, if the state  of the sensor doesn't leak privacy info, a
randomized SPI is not necessary.
                                  """

> 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.

> whether the SPI is truly random or selected in a way that identifies the
The text says random SPI does not guarantee privacy sensitive information
is not leaked.

> I do not know of a generic claim like this for ESP. Can a reference be

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.

"""

In general, rekeying is done to avoid decrypting previous traffic in case
> of a key compromise.

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.

> 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 ?

"""
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.
"""

> The language issue here inverts the meaning. What is meant is "so the

 I agreed and changed it.

> 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).

> 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.

> 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.
"""

> layer? Eg the packet size or energy use would not be different if one

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.

> No. minimal ESP is compatible with the standard ESP as mentioned in the
abstrct / intro:

"""
Instead, a minimal implementation is expected to be optimized for
constrained environment while remaining interoperable with implementations
of RFC 4303 ESP
"""

The document is limited to ESP RFC4303.

> "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.
 """

> Privacy concerned are exposed within the SPI section. Splitting the
section into multiple sections will make the document harder to read.

> Traffic shaping does not mean modifying traffic size.  I see traffic
shaping being used to describe optimization as well inferring activity from
the traffic.

>
>
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>

-- 
Daniel Migault
Ericsson