Comments from Benjamin Kaduk during IESG Conflict Review

[daveoran]

Comments on the document itself:

Section 2

Trust:

  Data authenticity is distinct from data trustworthiness, though
  the two concepts are related.  A packet is authentic if it has a
  valid name-to-content binding.  A packet is trustworthy, i.e., it
  comes from a reputable or trusted origin, if this binding is valid
  in the context of a trust model.  Section 6 discusses this
  further.

I think I see what is intended here, but distinguishing between "valid" and "valid in the context of a trust model" is a pretty subtle differentiation. Some more discussion about a given named entity being expected to produce certain content might help (but then again, might not).

Forwarding Plane:

  The canonical way of implementing packet forwarding in an ICN
  network relies on three data structures that capture a node's
  state: a Forwarding Interest Table (FIB), a Pending Interest
  Table (PIT), and a Content Store (CS).  It also utilizes Interest
  forwarding strategies which takes input from both FIB and
  measurements to make Interest forwarding decisions.  When a node

nit: "take input" to match "strategies" plural.

Section 3.1

Data packet Immutability:

  After a data packet is created, the cryptographic hash binding the
  name to the content ensures that if either the content or the name
  changes, that change will be detected and the packet discarded.

nit: previous discussion referred to the name-to-content binding as a "signature", not as a "hash".

Section 3.5

Nonce:

  A field of an Interest packet that transiently names an Interest
  instance (instance of Interest for a given name).  Note: the use
  "nonce" as defined here for NDN does not imply semantics that
  satisfy all the properties of a cryptographic nonce as defined in,
  e.g.  [RFC4949].

RFC 4949 does not have a definition for "cryptographic nonce", so I assume just the regular definition for "nonce" is the intended reference. The only required attribute there is "random or non-repeating", with liveness guarantee and replay protection being only the "usual usage" (i.e., not required). While I assume I don't fully understand the nuance of ICNRG nonce usage, my understanding is that they are intended to be non-repeating, at least within some time window, and serve to tie specific expressions of interest to data responses. That is not exactly the "replay protection" of RFC 4949, though it is closely related, and I would argue that even the "non-repeating within a time window" property suffices to keep the ICN usage within the RFC 4949 definition.

Which is a long way of saying that I don't think this much disclaimer is needed.

Section 6

While the terms defined in this specification do not in and of themselves present new security considerations, the architectures which utilize the terms most certainly do. Readers should look at those specifications (e.g. [RFC8569], [NDN]) where various security considerations are addressed in detail.

This is a great formulation; thank you!

[daveoran]

Responses as captured in version -08

Section 2

• Trust: “Data authenticity is distinct from data trustworthiness, though the two concepts are related. A packet is authentic if it has a valid name-to-content binding. A packet is trustworthy, i.e., it comes from a reputable or trusted origin, if this binding is valid in the context of a trust model. Section 6 discusses this further.” I think I see what is intended here, but distinguishing between "valid" and "valid in the context of a trust model" is a pretty subtle differentiation. Some more discussion about a given named entity being expected to produce certain content might help (but then again, might not).

I was inclined to leave this as is, but perhaps adding something like what you suggest is actually helpful. So, I added the sentence before the reference section 6: “The trust model provides assurance that the name used for a given piece of content is appropriate for the value of the content”. We can remove or further change this during RFC editor processing if you think this doesn’t help (or further obfuscates).

• Forwarding Plane: The canonical way of implementing packet forwarding in an ICN network relies on three data structures that capture a node's state: a Forwarding Interest Table (FIB), a Pending Interest Table (PIT), and a Content Store (CS). It also utilizes Interest forwarding strategies which takes input from both FIB and measurements to make Interest forwarding decisions. When a node” nit: "take input" to match "strategies" plural.

Fixed.

Section 3.1

Data packet Immutability: “After a data packet is created, the cryptographic hash binding the name to the content ensures that if either the content or the name changes, that change will be detected and the packet discarded. nit: previous discussion referred to the name-to-content binding as a "signature", not as a "hash".

Right, changed to “signature”

Section 3.5

Nonce:”A field of an Interest packet that transiently names an Interest instance (instance of Interest for a given name). Note: the use "nonce" as defined here for NDN does not imply semantics that satisfy all the properties of a cryptographic nonce as defined in, e.g. [RFC4949].” RFC 4949 does not have a definition for "cryptographic nonce", so I assume just the regular definition for "nonce" is the intended reference. The only required attribute there is "random or non-repeating", with liveness guarantee and replay protection being only the "usual usage" (i.e., not required). While I assume I don't fully understand the nuance of ICNRG nonce usage, my understanding is that they are intended to be non-repeating, at least within some time window, and serve to tie specific expressions of interest to data responses. That is not exactly the "replay protection" of RFC 4949, though it is closely related, and I would argue that even the "non-repeating within a time window" property suffices to keep the ICN usage within the RFC 4949 definition. Which is a long way of saying that I don't think this much disclaimer is needed.

The concern was that NDN is very loose in their nonce requirements. For example with guessable nonces an attacker could cause some PIT state to be created by one incoming interest which might inappropriately cause aggregation of interests from a victim that should have been forwarded. The point about RFC4949 not defining cryptographic nonces is well taken however. I toned down the disclaimed to “Note: the specification defining nonces in NDN do not necessarily satisfy all the properties of nonces as discussed in RFC4949”.

Is that better?

Section 6

• “While the terms defined in this specification do not in and of themselves present new security considerations, the architectures which utilize the terms most certainly do. Readers should look at those specifications (e.g. [RFC8569], [NDN]) where various security considerations are addressed in detail.” This is a great formulation; thank you!

We appreciate the vote of confidence!