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

[Daniel Migault <[e-mail]>]

Thanks Roman for the feed back!

Yours,
Daniel

On Mon, Sep 12, 2022 at 1:41 PM Roman Danyliw <[e-mail]> wrote:

> Hi Daniel!
>
>
>
> Thank you for the updates in -09, -10 and -11 and the explanations below.
> It addresses all of my DISCUSS and COMMENT feedback.  I’ve cleared my
> ballot.
>
>
>
> Roman
>
>
>
> *From:* Daniel Migault <[e-mail]>
> *Sent:* Thursday, April 7, 2022 1:29 PM
> *To:* Roman Danyliw <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail]; Mohit Sethi <
> [e-mail]>; [e-mail];
> [e-mail]
> *Subject:* Re: [Lwip] Roman Danyliw's Discuss on
> draft-ietf-lwig-minimal-esp-09: (with DISCUSS and COMMENT)
>
>
>
> 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
>


-- 
Daniel Migault
Ericsson