Re: [Lwip] Roman Danyliw's Discuss on draft-ietf-lwig-minimal-esp-09: (with DISCUSS and COMMENT)

[Daniel Migault <[e-mail]>]

Hi Roman,

Thanks for the review. Please find my responses and let me know if your
concerns are addressed.

Yours,
Daniel

On Wed, Apr 6, 2022 at 10:42 PM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-lwig-minimal-esp-09: 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:
> ----------------------------------------------------------------------
>
> ** Section 5.  The paragraph starting with “As the generation of dummy
> packets
> …” would benefit from refinement.  It starts with saying dummy packets
> “may be
> avoided”, but the second half of the paragraph argues the opposite.


The idea is to indicate that a minimal esp is not expected to send a dummy
packet unless there is a strong reason for doing it. In other words, we do
not prevent - and cannot prevent it in an informational document - to send
dummy packets.
My understanding of the text is that:
* The first sentence does not prevent sending dummy packet while saying it
is likely to not send dummy packets.
* The second sentence "More especially..." provides more details on why
it is unlikely to send dummy packets
* The third sentence "On the other..." mentions there may be some reasons
for still sending these dummy packets.

I suspect the problem is the interpretation of "may not". If so I am
wondering if replacing it by "may or may not" would clarify the text.

The use
> cases of constrained devices concerned about device lifetimes (first half
> of
> the paragraph) doesn’t seem mutually exclusive from those with dedicated
> applications (second half).  I recommend being cleared on the assumptions
> guiding the use of dummy packets.
>
>  Correct. I do see "On the other hand" correlating two independent
proposals that need to be balanced.

I am happy to take any clarifying text but I am wondering if adding "also"
would address the concern.

The paragraph would become:

OLD:
 As the generation of dummy packets is subject to local management and
   based on a per-SA basis, a minimal ESP implementation may not
   generate such dummy packet.  More especially, in constraint
   environment sending dummy packets may have too much impact on the
   device life time, and so may be avoided.  On the other hand,
   constraint nodes may be dedicated to specific applications, in which
   case, traffic pattern may expose the application or the type of node.
   For these nodes, not sending dummy packet may have some privacy
   implication that needs to be measured.  However, for the same reasons
   exposed in Section 5 traffic shaping at the IPsec layer may also
   introduce some traffic pattern, and on constraint devices the
   application is probably the most appropriated layer to limit the risk
   of leaking information by traffic shaping.

NEW:
 As the generation of dummy packets is subject to local management and

  based on a per-SA basis, a minimal ESP implementation **may or** may not

  generate such dummy packet.  More especially, in constraint

  environment sending dummy packets may have too much impact on the

  device life time, and so may be avoided.  On the other hand,

  constraint nodes may **also** be dedicated to specific applications, in
which
  case, traffic pattern may expose the application or the type of node.

  For these nodes, not sending dummy packet may have some privacy

  implication that needs to be measured.  However, for the same reasons

  exposed in Section 5 traffic shaping at the IPsec layer may also

  introduce some traffic pattern, and on constraint devices the

  application is probably the most appropriated layer to limit the risk

  of leaking information by traffic shaping.


>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to David Mandelberg for the SECDIR review.
>
> I support Paul Wouter’s DISCUSS position.


> ** IDnits reports:
>
>   == Unused Reference: 'RFC2119' is defined on line 553, but no explicit
>      reference was found in the text


>   == Unused Reference: 'RFC8174' is defined on line 581, but no explicit
>      reference was found in the text
>

solved.

>
> ** Please add a privacy consideration section (or merge it into the
> Security
> Considerations) to say that the practices suggested in Section 2.1 will
> reduce
> privacy/security by enabling device fingerprinting.
>
> I understand the suggestion to add a privacy consideration section that
will be generic and point to concerns exposed in the other sections. I like
this idea that prevents splitting sections across the document and make the
document hard to read. Here is the section i propose:

<t>Preventing the leakage of privacy sensitive information is a hard
problem to solve and usually result in balancing the information
potentially being leaked to the cost associated with the counter measures.
This problem is not inherent to the minimal ESP described in this document
and also concerns the use of ESP in general. </t>

<t>This document targets minimal implementations of ESP and as such
describes some minimalistic way to implement ESP.
In some cases, this may result in potentially exposing privacy sensitive
pieces of information.
This document describes these privacy implications so the designer can take
the appropriate decisions given the specificities of a given environment
and deployment. </t>

<t>The main risks associated with privacy is the ability to identify an
application or a device by analyzing the traffic which is designated as
traffic shaping.
As discussed in <xref target="sec-spi"/>, the use in some very specific
context of non randomly generated SPI might in some cases ease the
determination of the device of the application.
Similarly, padding provides limited capabilities to obfuscate the traffic
compared to those provided by TFC. Such consequence on privacy as detailed
in <xref target="sec-padding"/>. </t>

** Section 2.
>    For nodes supporting only unicast communications, this document
>    recommends to index SA with the SPI only.
>
> I don’t follow how this is new guidance.  Section 4.1 of RFC4301 only
> seems to
> already suggest that:
>
> For an SA used to carry unicast traffic, the Security Parameters
>    Index (SPI) by itself suffices to specify an SA.  ... However, as a
> local
>    matter, an implementation may choose to use the SPI in conjunction with
> the
>    IPsec protocol type (AH or ESP) for SA identification.
>
>
I agree the document does not contradict 4301 which is good in my opinion
as, contradiction with 4301 would be a problem. The reason we mention is
that using only the SPI greatly simplifies the SA lookup "longest match"
algorithm (detailed below). If someone implements ESP, I have the
impression "For nodes supporting only unicast communications, this document
recommends to index SA with the SPI only." will be helpful compared to
section 4.1.

>From section 4.1 of 4301:

 Each entry in the SA Database (SAD) (Section 4.4.2) must indicate
   whether the SA lookup makes use of the destination IP address, or the
   destination and source IP addresses, in addition to the SPI.  For
   multicast SAs, the protocol field is not employed for SA lookups.
   For each inbound, IPsec-protected packet, an implementation must
   conduct its search of the SAD such that it finds the entry that
   matches the "longest" SA identifier.  In this context, if two or more
   SAD entries match based on the SPI value, then the entry that also
   matches based on destination address, or destination and source
   address (as indicated in the SAD entry) is the "longest" match.  This
   implies a logical ordering of the SAD search as follows:

      1. Search the SAD for a match on the combination of SPI,
         destination address, and source address.  If an SAD entry
         matches, then process the inbound packet with that
         matching SAD entry.  Otherwise, proceed to step 2.

      2. Search the SAD for a match on both SPI and destination address.
         If the SAD entry matches, then process the inbound packet
         with that matching SAD entry.  Otherwise, proceed to step 3.

      3. Search the SAD for a match on only SPI if the receiver has
         chosen to maintain a single SPI space for AH and ESP, and on
         both SPI and protocol, otherwise.  If an SAD entry matches,
         then process the inbound packet with that matching SAD entry.
         Otherwise, discard the packet and log an auditable event.



> ** Section 2
>
>    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.
>
> Is this temperature/wind sensor example assuming that potentially leaking
> model
> and version information is not privacy sensitive (as established as
> possible in
> the previous paragraph)?

Is the door sensor example assuming that it is communicating on a local
> network?  This is a design decision that this class of sensor could never
> be
> integrated otherwise?
>
>
I think the paragraph says:
The use of random SPI are preferred in general as they reduce the leakage
of information, but also warns that the solely use of random SPI does not
guarantee no privacy sensitive information is being leaked.
To understand what privacy sensitive information is leaked, the document
recommends a careful analysis.
Follows an example, whose purpose is to illustrate the kind of trade off
that may exist. This is where the temperature sensors come into play.
The example wants to stress there exists compromises. Let me see if the
following text addresses your concerns:

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 these examples, the privacy aspect of the information itself might be
limited. Being able to determine the version of the sensor to potentially
take control of it may also have some limited security consequences. Of
course this depends on the context these sensors are being used.
If the risks associated to privacy and security are acceptable, a
randomized SPI is not necessary. In any case, for such constrained sensors,
it remains better to have secure communications with non random SPI as
opposed to no security.

 ** Section 3.
>    For inbound traffic, this document recommends that any receiver
>    provides anti-replay protection,
>
> What is the intent of this guidance – is it that “this document recommends
> that
> all receivers provide anti-replay protection”?  I’m having difficulty
> parsing
> the “any receiver”.
>

The document recommends if you implement a receiving node, you implement
anti-replay. I would propose the following changes but I am happy to change
it if you have better wording.

For inbound traffic, this document recommends that receiver implement
anti-replay protection,


> ** Section 4.  Per the paragraph starting with “As a result, TFC cannot be
> enabled …”, I don’t understand why this text is needed.  The previous
> paragraph
> established that TFC is not recommended for this profile.  Why comment on
> an
> extension which is not part of the profile?
>

The paragraph discusses the impact of not using TFC for those that were
relying on it. Does the following text address your concern ?
OLD:
As a result, TFC cannot be enabled with minimal ESP, and communication
protection that were re
lying on TFC will be more sensitive to traffic shaping.

NEW:
Communication protection that was relying on TFC will be more sensitive to
traffic shaping.

>
> ** Section 4.  Per the paragraph starting with “some constrained nodes …”,
> is
> this paragraph also needed?  What minimal ESP guidance is the implementer
> intended to take from this text?
>

 The section is on padding, the paragraph warns that minimizing the padding
byte has some privacy implications. The intent of the paragraph is more for
the application.
Some constrained nodes that have limited battery lifetime may also prefer
avoiding sending extra padding bytes.  However, the same nodes may also be
very specific to an application and device.....


> ** Section 7.
>
>   This section lists some of the criteria that may be considered.
>
> Considered in support of what decision?
>
> Does the following text address your concern ?

OLD:
This section lists some of the criteria that may be considered

NEW:
This section lists some of the criteria that may be considered to select
the appropriate cryptographic suite.


> ** Section 7.
>   As a result, the list is provided as informational:
>
> How should the reader use an informational list in an information document
> which doesn’t use any RFC2119 normative language?
>
> I have removed
As a result, the list is provided as informational

** Section 7.
>     In the latter case, authenticated
>     encryption must always be considered [RFC8221].
>
> What does it mean to “consider” authenticated encryption?  Should it be
> used as
> a first choice, unless use is not possible?
>
> yes. The previous sentences says: "ESP can be used to authenticate only
or to encrypt the communication." and authenticated encryption cannot be
used when the traffic is authenticated only.
I propose the following change to address a previous concern.
OLD:
In the latter case, authenticated encryption must always be considered
 NEW:
In the latter case, authenticated encryption is RECOMMENDED.

I think the confusion results from a must being interpreted by myself as
MUST.

** Section 7.
>       When the key is likely to be re-used
>       across reboots, this document recommends to consider algorithms
>        that are nonce misuse resistant such as,
>
> What does it mean to “recommend to consider”?
>
> Does the following text address your concern?

algorithms that are nonce misuse resistant such as, for example, AES-SIV
<xref target="RFC5297"/>, AES-GCM-SIV <xref target="RFC8452"/> or Deoxys-II
<xref target="DeoxysII"/> are RECOMMENDED.

** Section 7.  Bullet 3, Interoperability.  The guidance being given to
> implementers isn’t clear to me.
>
> The text is trying to say that there is a compromise to
implement algorithms that are also shared by other nodes, but that is not
a  reason to implement non secure cryptographic algorithms.


> Editorial
> -- Section 3.  Typo.  s/know whereas the received/know whether the
> received/
>
> -- Section 3. Editorial. s/sending a temperature/sending a temperature
> measurement/
>
> -- Section 3.  s/sending a temperature/sending a temperature measurement/
>
> -- Section 4.  Typo. s/TFC has not yet being/TFC has not been/
>
> -- Section 5.  Typo. s/More especially, in constrained /Specifically, in a
> constrained/
>
> -- Section 5.  Typo. s/and so may be avoided/a should be avoided/.
>
> -- Section 7.  s/overtime/over time/
>
> -- Section 7.  Typo.  s/not be known vulnerable or weak/must not use
> ciphers
> known to be vulnerable or weak/
>
> -- Section 9.  Editorial.  s/for each field/for each ESP field/.
>
>
> fixed

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


-- 
Daniel Migault
Ericsson