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

[Paul Wouters via Datatracker <[e-mail]>]

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