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

[Roman Danyliw via Datatracker <[e-mail]>]

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


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

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

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

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

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

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

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

** Section 7.

  This section lists some of the criteria that may be considered.

Considered in support of what decision?

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

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

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

** Section 7.  Bullet 3, Interoperability.  The guidance being given to
implementers isn’t clear to me.

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