Subject: Re: [icnrg] [irsg] Final IRSG poll on draft-irtf-icnrg-terminology-05

From: "David R. Oran" <[email-masked]>
Date: Tue, 01 Oct 2019 09:06:54 -0400

Stephen & IRSG,

Thanks for these insightful comments. It’s definitely not too late to improve the document! After giving this some time for others to weigh in I didn’t get any further thoughts from the other authors, so excuse the delay - please take a look and make any further suggestions for based on the stuff below.

Once we settle on the outstanding questions, I’ll update the draft and resubmit to hopefully finish the IRSG poll.

Thanks again for your time and effort on this!

DaveO.

On 23 Sep 2019, at 20:59, Stephen Farrell wrote:

> Hiya,
>
> On 23/09/2019 23:12, Colin Perkins wrote:
>> IRSG members,
>>
>> This is to initiate a final IRSG poll on
>> draft-irtf-icnrg-terminology-05 with a deadline of 14 October 2019.
>
> Given that I'm coming to the game very late, I am fine
> with a ready to publish vote on this.
>
> However, had I not been so late, I'd have said this was
> not ready as I'm not sure that any of the cryptographic
> mechanism terms are properly handled.
>
Could you elaborate a bit on any stuff beyond the specifics in your comments (which we’ll try to address). We certainly don’t want to either cause confusion or be out of step with current usage.

> In particular I wonder if data packet signatures are
> really checked or not (with existing s/w)
Given this is a terminology draft, there’s no assertion that the definitions are in fact satisfied by any given implementation. Since you are curious, here’s the state of affairs as I understand it:

- The current NDN code base does in fact check signatures. While it is possible for an application to directly access the transmit/receive interfaces for NDN messages and hence do its own signature verification, general applications use one of two APIs (the most comprehensive being the “producer/consumer API - https://named-data.net/publications/techreports/tr17-consumer-producer-api/) which automatically does the verification.
- The current CCNx code base, Metis (https://github.com/parc-ccnx-archive/Metis) also verifies signatures automatically.
- Of course, just checking signatures without some notion of which signatures should be trusted to sign which packets isn’t terribly helpful. There’s a lot of good work here on trust schemas and automatons that use the name structures of objects and keys to decide what to trust. If you’re interested take a look at “Schematizing Trust in Named Data Networking (https://named-data.net/publications/schematizing_trust_ndn/). This is also implemented and used in some current applications (for an interesting use case, check out the just-published paper Lessons Learned Building a Secure, Network Measurement Framework using Basic NDN (https://conferences.sigcomm.org/acm-icn/2019/proceedings/icn19-20.pdf)

> and have to
> consider the descriptions of confidentiality as being
> mythical. I'd say fixing those parts could well be
> considered an inherent part of due diligence.
>
Well, the current NDN and CCNx designs only provide origin authentication of packets and leaves confidentiality and payload encryption to a layer above. Given that this terminology is intended to only address the usage of terms in the specifications of the NDN and CCNx protocols, what would you suggest here? While the document does have wider interest than just the NDN/CCNx communities, its genesis and value is mostly in ensuring the that the two designs use consistent terminology so the different design decisions can be compared when doing evaluations and building applications.

> Detailed comments/suggestions below.
>
> Cheers,
> S.
>
> - abstract: is ICN still "novel"?
>
Perhaps. A prior version of the document said “(ICN) is a new paradigm” and we changed it in -05. Would it be better to just say “paradigm”? I didn’t make any change to the text.

> - intro: Is there really an intention to publish an equivalent for
>   e.g.  NetInf? Be nice if there were, but it seems less likely now
> than perhaps when this effort started.
>
Good point. We’ll change it to “may be the subject…”

> - section 2: I refute the potential existence of an "irrefutable
>   binding":-) Probably better to not use such odd language in a
> terminology draft? (In case someone wants to discuss, consider a
> DNSpionage type attack against a CA issuing certificates for use in
> an ICN - doesn't matter if that'd be a hard or unlikely attack,
> it's enough that irrefutable is wrong.) Suggest s/irrefutable
> binding/strong cryptographic binding/
>
I like your suggestion. We’ll make this change.

> - s2: "Data authenticity and encryption" - hmm. Last time I asked a
>   student implementing ICN, he couldn't find any code that actually
> enforced signature verification. Is that still the case? If so,
> then it seems wrong to perpetuate a myth like this. If not - great!
See above in the answer to your general comment.

> And where can I find sample logs for mismatching interest and data
> packet caught via signature failure?
I don’t know if there’s anything beyond debug logs for the code, but this question doesn’t seem in scope for a terminology document. Is it ok to just let this slide?

> Secondly, the idea that it's
> fine and dandy that confidentiality doesn't exist within ICN seems
> nicely 20th century.
Well, it most certainly does exist, but not in the L3 protocol machinery which is what this document is addressing. Perhaps we should put something in the introduction to correctly position this as not claiming to be terminology for the whole protocol architecture, but only for the Layer 3 protocols of NDN and CCNx. Would that at least somewhat alleviate the concern?

> All in all that paragraph seems misleading.  I
> think the best fix would be to make the description contingent,
> e.g. to say something like "s/w could (but mostly doesn't) drop
> data packets that don't match interests because of signature check
> failure." And maybe say "there is no ICN confidentiality service
> (sadly)" if we want to be clear.
>
I get it, but the current text is not a statement about what an implementation does; it hopefully specifies the terminology used to describe it.

> - s2: "Trust" - meh. I don't trust text with such definitions.
>   Also, a description of the concept of "Trust" that ends with
> "trust model" seems circular. I'd just delete that para - it only
> obfuscates and doesn't help.
>
I found the paragraph just fine, which probably says more about the authors’ naïveté than the actual state of affairs. I’d prefer to leave this or even better fix it, since it would be a possibly glaring omission to have a terminology document that doesn’t say anything about trust.

> - s2: "packet mule" - there is a "data mule" concept from DTN that
>   may be what's meant here. I think using that term and referring
> to something that defines it would be better than inventing the new
> term "packet mule." Later I find you even define the term "data
> mule" in 3.2 so just using that will be better.
>
Actually, I think we are being sloppy, since this isn’t enough like the data mule concept in DTN to introduce here. Mules typically store forwarding state and instructions in the packets themselves, which is’t what NDN and CCNx do. So, thanks for catching this. I propose we change this to simply say “It can also behave as a store and forward node, carrying an interest or Data Packet for some time before forwarding it”.

> - 3.1: "Data packet immutability" - I don't believe it myself:-) If
>   you hand me a packet, I can change and forward it. I think what
> you mean is that change can be detected (in principle).  I don't
> get the last sentence.
>
I can see why this might be horribly confusing to somebody not “inside the ICN tent pissing out”. The idea which seems to not come across in the text is that ICN cares fundamentally about the relationship between names and data and in the case of NDN and CCNx makes the binding between a name and the corresponding data content immutable, with that binding enforced cryptographically. You therefore cannot, “reuse” as name to refer to a different set of bits. If this makes more sense to folks I can craft some modified language in the document. One caveat is that there is a political dimension to the definitions in the terminology draft, as it was the result of some delicate negotiation between the NDN and CCNx camps back some years ago when the two architectures were a lot different than they are today.

> - 3.3: I was puzzled by the ordering of terms here. Why be coy
>   about that? IOW, be good to explain to the reader why terms are
> in this order. (My guess: to avoid forward refs.)
>
Frankly I’m not sure what the particular motivation was. Since I doubt the usage model for this specification is to act as a “dictionary”, alphabetical or some other canonical ordering doesn’t seem to be important. Since you noticed, do you have some suggestion for what would be better? In some cases there is the advantage of no forward references, but in others it doesn’t seem to matter. I’m not proposing any change here.

> - 3.3: If there exists a useful definition of stateful forwarding,
>   then why is there not one for stateless forwarding?
Because stateless forwarding is not used anywhere in CCNx or NDN? It may be that anybody sufficiently clued knows that the “other” architecture is IP, which does stateless forwarding, and “everybody knows” what that is.

> If there is
> not then why is there not just forwarding? In which case, why do we
> need an entry in 3.3?
>
I think the reasoning is to tie the terminology directly to the form of the state that must be kept by a forwarder. Do you think this does in fact need fixing? I’d prefer to leave it as is.

> - 3.3: "data packet" ... the "and is directly secured" phrase - is
>   that true? (See earlier.)
>
Yes, I think so. Should we add “directly secured through cryptographic integrity mechanisms”?

> - 3.5: "name" ... the assertion of being "semantically meaningful"
>   seems unnecessary to me and also impossible to verify. Maybe just
> delete the phrase as it's qualified with a "usually" anyway?
>
I don’t think saying “usually semantically meaningful” is problematic, but we would not lose a lot by deleting it. I’d prefer to keep it given that there’s a lot of active work on name schemas for NDN and CCNx which do in fact delve deeply into structuring names that can be assigned meaning by applications, and in some cases, presented to users in UIs.

> - 3.5: SHA256 probably calls for a reference.
>
Will add. Thanks.

> - 3.5: "nonce" - this has a cryptographic definition that is
>   perhaps not the same (see RFC4949). Saying that explicitly would
> be good.
>
Good point. As an aside CCNx does not use nonces, but NDN still does, although they don’t have as central a role in loop detection and retransmission as they used to now that NDN added a hop limit like CCNx has. Nevertheless we’ll add a note that the usage does not satisfy all the properties of a cryptographic nonce and add the reference to RFC4949.

> - 3.7: "data integrity" also protects against deliberate
>   modification, as well as corruption.
>
Good point. Will add.

> - 3.7: "authenticity" - using HMAC? Really? That seems like a
>   totally broken idea for an ICN. Surely any symmetric scheme
> like that couldn't work with caching without allow forgery?
>
It would be good if you could elaborate here. Anybody with the key can forge, including caches, so the implicit assumption is that the “trusted domain” includes the caches. Do you have a suggestion other than getting rid of mention of symmetric keying? As an aside, we do have a TLS-like keying protocol for use cases that involve two-party exchanges - take a look at https://tools.ietf.org/id/draft-wood-icnrg-ccnxkeyexchange-01.html if you’re interested.

> - 3.7: all the "... confidentiality" paragraphs - this seems like
>   it'd be better omitted given the utter lack of ways in which such
> a service can be provided as part of an ICN.
I’d prefer to leave this in, but appreciate the earlier comments about the protocols the terms apply to not having confidentiality machinery built in. Would it be acceptable to add to each of these a statement that the CCNx and NDN layer 3 protocols do not provide such confidentiality and it expected that higher layers provide such?

DaveO

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Oct 2019 15:09:15 +0100

Hi Dave,

On 01/10/2019 14:06, David R. Oran wrote:
> Stephen & IRSG,
> 
> Thanks for these insightful comments. It’s definitely not too late to
> improve the document! After giving this some time for others to weigh
> in I didn’t get any further thoughts from the other authors, so
> excuse the delay - please take a look and make any further
> suggestions for based on the stuff below.
> 
> Once we settle on the outstanding questions, I’ll update the draft
> and resubmit to hopefully finish the IRSG poll.
> 

No problem. And once again, as I'm late to this game,
I really do think it'd be fine to publish without my
comments being addressed. (If we can improve it anyway,
that's great, but I really don't want to try arm-wrestle
the RG into sharing my opinions:-)

>> Given that I'm coming to the game very late, I am fine with a ready
>> to publish vote on this.
>> 
>> However, had I not been so late, I'd have said this was not ready
>> as I'm not sure that any of the cryptographic mechanism terms are
>> properly handled.
>> 
> Could you elaborate a bit on any stuff beyond the specifics in your
> comments (which we’ll try to address). We certainly don’t want to
> either cause confusion or be out of step with current usage.

There wasn't anything else, sorry, just the stuff below.

> 
>> In particular I wonder if data packet signatures are really checked
>> or not (with existing s/w)
> Given this is a terminology draft, there’s no assertion that the
> definitions are in fact satisfied by any given implementation. Since
> you are curious, here’s the state of affairs as I understand it:
> 
> - The current NDN code base does in fact check signatures. While it
> is possible for an application to directly access the
> transmit/receive interfaces for NDN messages and hence do its own
> signature verification, general applications use one of two APIs (the
> most comprehensive being the “producer/consumer API -
> https://named-data.net/publications/techreports/tr17-consumer-producer-api/)
> which automatically does the verification. - The current CCNx code
> base, Metis (https://github.com/parc-ccnx-archive/Metis) also
> verifies signatures automatically. - Of course, just checking
> signatures without some notion of which signatures should be trusted
> to sign which packets isn’t terribly helpful. There’s a lot of good
> work here on trust schemas and automatons that use the name
> structures of objects and keys to decide what to trust. If you’re
> interested take a look at “Schematizing Trust in Named Data
> Networking
> (https://named-data.net/publications/schematizing_trust_ndn/). This
> is also implemented and used in some current applications (for an
> interesting use case, check out the just-published paper Lessons
> Learned Building a Secure, Network Measurement Framework using Basic
> NDN
> (https://conferences.sigcomm.org/acm-icn/2019/proceedings/icn19-20.pdf)

Good to hear. Could be that the student was playing with
some other API.

> 
>> and have to consider the descriptions of confidentiality as being 
>> mythical. I'd say fixing those parts could well be considered an
>> inherent part of due diligence.
>> 
> Well, the current NDN and CCNx designs only provide origin
> authentication of packets and leaves confidentiality and payload
> encryption to a layer above. Given that this terminology is intended
> to only address the usage of terms in the specifications of the NDN
> and CCNx protocols, what would you suggest here? While the document
> does have wider interest than just the NDN/CCNx communities, its
> genesis and value is mostly in ensuring the that the two designs use
> consistent terminology so the different design decisions can be
> compared when doing evaluations and building applications.

Specific suggestions below, but in general, if no ICN
approach provides confidentiality then I'm not sure why
there need be any mention of "Encryption" in this draft.

>> Cheers, S.
> Perhaps. A prior version of the document said “(ICN) is a new
> paradigm” and we changed it in -05. Would it be better to just say
> “paradigm”? I didn’t make any change to the text.

It's a nit:-)

> Good point. We’ll change it to “may be the subject…”

Yep, that's likely better.

>> DNSpionage type attack against a CA issuing certificates for use
>> in an ICN - doesn't matter if that'd be a hard or unlikely attack, 

Cool.

> 
>> - s2: "Data authenticity and encryption" - hmm. Last time I asked
>> a student implementing ICN, he couldn't find any code that
>> actually enforced signature verification. Is that still the case?
>> If so, then it seems wrong to perpetuate a myth like this. If not -
>> great!

Good again that signatures are being checked. I still
wonder if it's reasonable to say that any node "can
validate" authenticity though - are forwarders really
able to do that with all data packets in practice? (Or
are the relevant signature-verification APIs only for
requestors?)

> I don’t know if there’s anything beyond debug logs for the code, but
> this question doesn’t seem in scope for a terminology document. Is it
> ok to just let this slide?

Sure:-)

> 
>> Secondly, the idea that it's fine and dandy that confidentiality
>> doesn't exist within ICN seems nicely 20th century.
> Well, it most certainly does exist, but not in the L3 protocol
> machinery which is what this document is addressing. Perhaps we
> should put something in the introduction to correctly position this
> as not claiming to be terminology for the whole protocol
> architecture, but only for the Layer 3 protocols of NDN and CCNx.
> Would that at least somewhat alleviate the concern?
> 
>> All in all that paragraph seems misleading.  I think the best fix
>> would be to make the description contingent, e.g. to say something
>> like "s/w could (but mostly doesn't) drop data packets that don't
>> match interests because of signature check failure." And maybe say
>> "there is no ICN confidentiality service (sadly)" if we want to be
>> clear.
>> 
> I get it, but the current text is not a statement about what an
> implementation does; it hopefully specifies the terminology used to
> describe it.

TBH, I still find it odd. FWIW, here's what I'd
suggest:

OLD:

   *Data Authenticity and Encryption*:

      Any data consumer and network element can validate the
      authenticity of a Data packet by verifying its cryptographic name-
      to-content binding.  In contrast, whether a Data packet's content
      (payload) itself is encrypted or not is irrelevant to the ICN
      network.  The use and management of content encryption keys is an
      application-layer concern.

NEW:

   *Data Authenticity*:

      Any data consumer and network element can (in principle)
      validate the authenticity of a Data packet by verifying
      its cryptographic name-to-content binding. Note that
      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, but it may
      still be unwise to "trust" the content for any particular
      purpose.

Adding a sentence to the intro about confidentiality might
also be useful, e.g. "ICN architectures generally don't
provide data confidentiality, which is treated in ICN as
an application layer concern."

>> Also, a description of the concept of "Trust" that ends with "trust
>> model" seems circular. I'd just delete that para - it only 
> I found the paragraph just fine, which probably says more about the
> authors’ naïveté than the actual state of affairs. I’d prefer to
> leave this or even better fix it, since it would be a possibly
> glaring omission to have a terminology document that doesn’t say
> anything about trust.

In my suggestion above, I include what I think is the correct
bit of that. While I still don't think a definition of "trust"
as an isolated term is useful, I guess including the current
term isn't the end of the world:-)

>> may be what's meant here. I think using that term and referring to
>> something that defines it would be better than inventing the new 
> Actually, I think we are being sloppy, since this isn’t enough like
> the data mule concept in DTN to introduce here. Mules typically store
> forwarding state and instructions in the packets themselves, which
> is’t what NDN and CCNx do. So, thanks for catching this. I propose we
> change this to simply say “It can also behave as a store and forward
> node, carrying an interest or Data Packet for some time before
> forwarding it”.

That's better yes. (And thanks for the clarification, I hadn't
grokked the difference with DTN data mules myself.)

> 
>> - 3.1: "Data packet immutability" - I don't believe it myself:-)
>> If you hand me a packet, I can change and forward it. I think what 
> I can see why this might be horribly confusing to somebody not
> “inside the ICN tent pissing out”. The idea which seems to not come
> across in the text is that ICN cares fundamentally about the
> relationship between names and data and in the case of NDN and CCNx
> makes the binding between a name and the corresponding data content
> immutable, with that binding enforced cryptographically. You
> therefore cannot, “reuse” as name to refer to a different set of
> bits. If this makes more sense to folks I can craft some modified
> language in the document. One caveat is that there is a political
> dimension to the definitions in the terminology draft, as it was the
> result of some delicate negotiation between the NDN and CCNx camps
> back some years ago when the two architectures were a lot different
> than they are today.

Ok. I'd suggest s/cannot change/cannot change without
likely being discarded/ maybe and s/is mutable/is
intended to be mutable/ - does that help?

>> about that? IOW, be good to explain to the reader why terms are in
>> this order. (My guess: to avoid forward refs.)
>> 
> Frankly I’m not sure what the particular motivation was. Since I
> doubt the usage model for this specification is to act as a
> “dictionary”, alphabetical or some other canonical ordering doesn’t
> seem to be important. Since you noticed, do you have some suggestion
> for what would be better? In some cases there is the advantage of no
> forward references, but in others it doesn’t seem to matter. I’m not
> proposing any change here.

Fair 'nuff, 'twas a nit:-)

> Because stateless forwarding is not used anywhere in CCNx or NDN? It
> may be that anybody sufficiently clued knows that the “other”
> architecture is IP, which does stateless forwarding, and “everybody
> knows” what that is.
> 
>> If there is not then why is there not just forwarding? In which
>> case, why do we need an entry in 3.3?
>> 
> I think the reasoning is to tie the terminology directly to the form
> of the state that must be kept by a forwarder. Do you think this does
> in fact need fixing? I’d prefer to leave it as is.

I do wonder if there'll really be no stateless forwarding
if ICN grows, but fair enough.

> cryptographic integrity mechanisms”?

That'd be better yes. I'd even go for s/integrity/signature/
(but see below).

> I don’t think saying “usually semantically meaningful” is
> problematic, but we would not lose a lot by deleting it. I’d prefer
> to keep it given that there’s a lot of active work on name schemas
> for NDN and CCNx which do in fact delve deeply into structuring names
> that can be assigned meaning by applications, and in some cases,
> presented to users in UIs.

Ok.

>> perhaps not the same (see RFC4949). Saying that explicitly would be
>> good.
>> 
> Good point. As an aside CCNx does not use nonces, but NDN still does,
> although they don’t have as central a role in loop detection and
> retransmission as they used to now that NDN added a hop limit like
> CCNx has. Nevertheless we’ll add a note that the usage does not
> satisfy all the properties of a cryptographic nonce and add the
> reference to RFC4949.

Grand.

>> totally broken idea for an ICN. Surely any symmetric scheme like
>> that couldn't work with caching without allow forgery?
>> 
> It would be good if you could elaborate here. Anybody with the key
> can forge, including caches, so the implicit assumption is that the
> “trusted domain” includes the caches. Do you have a suggestion other
> than getting rid of mention of symmetric keying? 

Not really, sorry;-) It could be that I'm too out of date
with ICN, but I'd have thought that the authenticity
properties required signatures - with HMAC anyone with the
key can, as you say, muck with anything. I'm also not clear
what constitutes a "domain" for ICN - that is in fact the
only use of the term in the document. (And see earlier for
my allergy with "trusted":-)

> As an aside, we do
> have a TLS-like keying protocol for use cases that involve two-party
> exchanges - take a look at
> https://tools.ietf.org/id/draft-wood-icnrg-ccnxkeyexchange-01.html if
> you’re interested.

No time today sorry;-)

>> it'd be better omitted given the utter lack of ways in which such a
>> service can be provided as part of an ICN.
> I’d prefer to leave this in, but appreciate the earlier comments
> about the protocols the terms apply to not having confidentiality
> machinery built in. Would it be acceptable to add to each of these a
> statement that the CCNx and NDN layer 3 protocols do not provide such
> confidentiality and it expected that higher layers provide such?

I guess. OTOH, defining terms for things-not-done seems odd
to me. To give an example, if there were some (higher layer)
scheme for confidentiality for interests and payloads that
might well require two signatures (one on plaintext one on
ciphertext) or some other new concept that isn't the same
as data authenticity as defined here, so I'm not sure it's
useful to define these terms here.

And again, just to re-emphasise - none of the above ought be
considered as me objecting to publication.

Cheers,
S.

> 
> 
> 
> DaveO
> 
> 
> _______________________________________________ icnrg mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/icnrg
>

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 02 Oct 2019 09:12:03 -0400

Snipping out stuff that doesn’t directly address changes in the doc, and indicating what is in the -06 version of the draft. Thanks again Stephen for the quick and very clear reply!

I did the edits and posted the revision. You can find it here:
	https://www.ietf.org/internet-drafts/draft-irtf-icnrg-terminology-06.txt

Let me and the document Shepherd (Börje) if this resolves the comments and we can proceed to publication.

Thanks and best,
DaveO.

>> “paradigm”? I didn’t make any change to the text.
Ok, no change then.

> Yep, that's likely better.
done.

>> I like your suggestion. We’ll make this change.
done.

> are the relevant signature-verification APIs only for
Well, of course not as the cost is too high. Where the tradeoff may change is with respect to cached data, where there are quite credible cache poisoning attack possibilities. What CCNx does is fairly nice (IMO). I can describe it if you are interested (not in the terminology doc of course…).

>> ok to just let this slide?
Ok, no change.

>       still be unwise to "trust" the content for any particular
I adopted your text. Thanks!

> an application layer concern."
I added the following to the intro:
“While this terminology document describes both confidentiality and integrity-related terms, it should be noted that ICN architectures like NDN and CCNx generally do not provide data confidentiality, which is treated in these architectures as an application layer concern.”

> term isn't the end of the world:-)
so, we can survive another day. Thanks. No change here.

> grokked the difference with DTN data mules myself.)
done. I also fixed the definition further along to say: “An ICN entity that temporarily stores and potentially carries an Interest or Data packet before forwarding it to next ICN entity. Note do not have all the properties of data mules as employed in the Delay/Disruption Tolerant Networking <xref target="rfc.4838">(DTN)</xref> specifications.”

> intended to be mutable/ - does that help?
I did a bit more surgery. How about:
	“After a data packet is created, the cryptographic hash binding the name to the content ensures that neither the content nor the name can change without that hange being detected and the packet discarded. If the content carried in a data packet is intended to be mutable, versioning of the name should be used, so that each version uniquely identifies an immutable instance of the content. This allows disambiguation of coordination in distributed systems.”

> Fair 'nuff, 'twas a nit:-)
Ok, thanks. No change.

> if ICN grows, but fair enough.
Ok, no change. There are in fact “PIT less” designs, but they are not entirely stateless.

> That'd be better yes. I'd even go for s/integrity/signature/
Ok. Done.

>> presented to users in UIs.
Thanks. No change then.

>>> - 3.5: SHA256 probably calls for a reference.
I referenced RFC6234. Is that the right one?

>> satisfy all the properties of a cryptographic nonce and add the
done. Added the following note: 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].

>>> modification, as well as corruption.
done.

> my allergy with "trusted":-)
I didn’t make any changes here.

> useful to define these terms here.
I don’t think it hurts to leave them so given you don’t feel strongly, I left things as they are.

> considered as me objecting to publication.
Sure, but your help in improving the document is very much appreciated. It’s had a long gestation period, so a bit longer if it results in a better result is perfectly ok.

DaveO.

> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Oct 2019 20:02:34 +0100

Hi Dave,

(While there may be bits in there I'd not write myself:-) I'm
happy to support publication of -06 as-is. Thanks for being
willing to adapt it.

Cheers,
S.

On 02/10/2019 14:12, David R. Oran wrote:
> Snipping out stuff that doesn’t directly address changes in the doc,
> and indicating what is in the -06 version of the draft. Thanks again
> Stephen for the quick and very clear reply!
> 
>  Let me and the document Shepherd (Börje) if this resolves the
> comments and we can proceed to publication.
> 
> Thanks and best, DaveO.
> 
> 
>>> paradigm” and we changed it in -05. Would it be better to just
>>> say “paradigm”? I didn’t make any change to the text.
>> 
>> It's a nit:-)
>> 
> Ok, no change then.
> 
>>> 
>>>> - intro: Is there really an intention to publish an equivalent
>>>> for e.g.  NetInf? Be nice if there were, but it seems less
>>>> likely now than perhaps when this effort started.
>>>> 
>>>> - section 2: I refute the potential existence of an
>>>> "irrefutable binding":-) Probably better to not use such odd
>>>> language in a terminology draft? (In case someone wants to
>>>> discuss, consider a DNSpionage type attack against a CA issuing
>>>> certificates for use in an ICN - doesn't matter if that'd be a
>>>> hard or unlikely attack, it's enough that irrefutable is
>>>> wrong.) Suggest s/irrefutable binding/strong cryptographic
>>>> binding/
>>>> 
>>>> - s2: "Data authenticity and encryption" - hmm. Last time I
>>>> asked a student implementing ICN, he couldn't find any code
>>>> that actually enforced signature verification. Is that still
>>>> the case? If so, then it seems wrong to perpetuate a myth like
>>>> this. If not - great!
>> Good again that signatures are being checked. I still wonder if
>> it's reasonable to say that any node "can validate" authenticity
>> though - are forwarders really able to do that with all data
>> packets in practice? (Or are the relevant signature-verification
>> APIs only for requestors?)
>> 
> Well, of course not as the cost is too high. Where the tradeoff may
> change is with respect to cached data, where there are quite credible
> cache poisoning attack possibilities. What CCNx does is fairly nice
> (IMO). I can describe it if you are interested (not in the
> terminology doc of course…).
> 
>>> 
>>>> And where can I find sample logs for mismatching interest and
>>>> data packet caught via signature failure?
>>> I don’t know if there’s anything beyond debug logs for the code,
>>> but this question doesn’t seem in scope for a terminology
>>> document. Is it ok to just let this slide?
>> 
>> Sure:-)
>> 
> Ok, no change.
> 
>>> 
>>>> Secondly, the idea that it's fine and dandy that
>>>> confidentiality doesn't exist within ICN seems nicely 20th
>>>> century.
>>> should put something in the introduction to correctly position
>>> this as not claiming to be terminology for the whole protocol 
>>> architecture, but only for the Layer 3 protocols of NDN and
>>> CCNx. Would that at least somewhat alleviate the concern?
>>> 
>>>> All in all that paragraph seems misleading.  I think the best
>>>> fix would be to make the description contingent, e.g. to say
>>>> something like "s/w could (but mostly doesn't) drop data
>>>> packets that don't match interests because of signature check
>>>> failure." And maybe say "there is no ICN confidentiality
>>>> service (sadly)" if we want to be clear.
>>>> 
>>> implementation does; it hopefully specifies the terminology used
>>> to describe it.
>> 
>> TBH, I still find it odd. FWIW, here's what I'd suggest:
>> 
>> OLD:
>> 
>> Any data consumer and network element can validate the authenticity
>> of a Data packet by verifying its cryptographic name- to-content
>> binding.  In contrast, whether a Data packet's content (payload)
>> itself is encrypted or not is irrelevant to the ICN network.  The
>> use and management of content encryption keys is an 
>> Any data consumer and network element can (in principle) validate
>> the authenticity of a Data packet by verifying its cryptographic
>> name-to-content binding. Note that 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, but
>> it may still be unwise to "trust" the content for any particular 
>> purpose.
>> 
>> Adding a sentence to the intro about confidentiality might also be
>> useful, e.g. "ICN architectures generally don't provide data
>> confidentiality, which is treated in ICN as an application layer
>> concern."
>> 
> I added the following to the intro: “While this terminology document
> describes both confidentiality and integrity-related terms, it should
> be noted that ICN architectures like NDN and CCNx generally do not
> provide data confidentiality, which is treated in these architectures
> as an application layer concern.”
> 
>>> 
>>>> "trust model" seems circular. I'd just delete that para - it
>>>> only obfuscates and doesn't help.
>>>> 
>>> I found the paragraph just fine, which probably says more about
>>> the authors’ naïveté than the actual state of affairs. I’d prefer
>>> to leave this or even better fix it, since it would be a
>>> possibly glaring omission to have a terminology document that
>>> doesn’t say anything about trust.
>> 
>> In my suggestion above, I include what I think is the correct bit
>> of that. While I still don't think a definition of "trust" as an
>> isolated term is useful, I guess including the current term isn't
>> the end of the world:-)
>> 
>>>> - s2: "packet mule" - there is a "data mule" concept from DTN
>>>> that may be what's meant here. I think using that term and
>>>> referring to something that defines it would be better than
>>>> inventing the new term "packet mule." Later I find you even
>>>> define the term "data mule" in 3.2 so just using that will be
>>>> better.
>>>> 
>>> Actually, I think we are being sloppy, since this isn’t enough
>>> like the data mule concept in DTN to introduce here. Mules
>>> typically store forwarding state and instructions in the packets
>>> themselves, which is’t what NDN and CCNx do. So, thanks for
>>> catching this. I propose we change this to simply say “It can
>>> also behave as a store and forward node, carrying an interest or
>>> Data Packet for some time before forwarding it”.
>> 
> done. I also fixed the definition further along to say: “An ICN
> entity that temporarily stores and potentially carries an Interest or
> Data packet before forwarding it to next ICN entity. Note do not have
> all the properties of data mules as employed in the Delay/Disruption
> Tolerant Networking <xref target="rfc.4838">(DTN)</xref>
> specifications.”
> 
>>> 
>>>> - 3.1: "Data packet immutability" - I don't believe it
>>>> myself:-) If you hand me a packet, I can change and forward it.
>>>> I think what you mean is that change can be detected (in
>>>> principle).  I don't get the last sentence.
>>>> 
>>> “inside the ICN tent pissing out”. The idea which seems to not
>>> come across in the text is that ICN cares fundamentally about
>>> the relationship between names and data and in the case of NDN
>>> and CCNx makes the binding between a name and the corresponding
>>> data content immutable, with that binding enforced
>>> cryptographically. You therefore cannot, “reuse” as name to refer
>>> to a different set of bits. If this makes more sense to folks I
>>> can craft some modified language in the document. One caveat is
>>> that there is a political dimension to the definitions in the
>>> terminology draft, as it was the result of some delicate
>>> negotiation between the NDN and CCNx camps back some years ago
>>> when the two architectures were a lot different than they are
>>> today.
>> 
>> Ok. I'd suggest s/cannot change/cannot change without likely being
>> discarded/ maybe and s/is mutable/is intended to be mutable/ - does
>> that help?
>> 
> I did a bit more surgery. How about: “After a data packet is created,
> the cryptographic hash binding the name to the content ensures that
> neither the content nor the name can change without that hange being
> detected and the packet discarded. If the content carried in a data
> packet is intended to be mutable, versioning of the name should be
> used, so that each version uniquely identifies an immutable instance
> of the content. This allows disambiguation of coordination in
> distributed systems.”
> 
>>> 
>>> “dictionary”, alphabetical or some other canonical ordering
>>> doesn’t seem to be important. Since you noticed, do you have some
>>> suggestion for what would be better? In some cases there is the
>>> advantage of no forward references, but in others it doesn’t seem
>>> to matter. I’m not proposing any change here.
>> 
>>>> - 3.3: If there exists a useful definition of stateful
>>>> forwarding, then why is there not one for stateless
>>>> forwarding?
>>> Because stateless forwarding is not used anywhere in CCNx or NDN?
>>> It may be that anybody sufficiently clued knows that the “other” 
>>> architecture is IP, which does stateless forwarding, and
>>> “everybody knows” what that is.
>>> 
>>>> If there is not then why is there not just forwarding? In
>>>> which case, why do we need an entry in 3.3?
>>>> 
>>> I think the reasoning is to tie the terminology directly to the
>>> form of the state that must be kept by a forwarder. Do you think
>>> this does in fact need fixing? I’d prefer to leave it as is.
>> 
>> I do wonder if there'll really be no stateless forwarding if ICN
>> grows, but fair enough.
>> 
>>>> - 3.3: "data packet" ... the "and is directly secured" phrase -
>>>> is that true? (See earlier.)
>>>> 
>> That'd be better yes. I'd even go for s/integrity/signature/ (but
>> see below).
>> 
> Ok. Done.
> 
>>> 
>>>> - 3.5: "name" ... the assertion of being "semantically
>>>> meaningful" seems unnecessary to me and also impossible to
>>>> verify. Maybe just delete the phrase as it's qualified with a
>>>> "usually" anyway?
>>>> 
>>> problematic, but we would not lose a lot by deleting it. I’d
>>> prefer to keep it given that there’s a lot of active work on name
>>> schemas for NDN and CCNx which do in fact delve deeply into
>>> structuring names that can be assigned meaning by applications,
>>> and in some cases, presented to users in UIs.
>> 
>> Ok.
>> 
> Thanks. No change then.
> 
>>> 
>>>> perhaps not the same (see RFC4949). Saying that explicitly
>>>> would be good.
>>>> 
>>> Good point. As an aside CCNx does not use nonces, but NDN still
>>> does, although they don’t have as central a role in loop
>>> detection and retransmission as they used to now that NDN added a
>>> hop limit like CCNx has. Nevertheless we’ll add a note that the
>>> usage does not satisfy all the properties of a cryptographic
>>> nonce and add the reference to RFC4949.
>> 
>> Grand.
>> 
> done. Added the following note: 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].
> 
>>> 
>>> It would be good if you could elaborate here. Anybody with the
>>> key can forge, including caches, so the implicit assumption is
>>> that the “trusted domain” includes the caches. Do you have a
>>> suggestion other than getting rid of mention of symmetric
>>> keying?
>> 
>> Not really, sorry;-) It could be that I'm too out of date with ICN,
>> but I'd have thought that the authenticity properties required
>> signatures - with HMAC anyone with the key can, as you say, muck
>> with anything. I'm also not clear what constitutes a "domain" for
>> ICN - that is in fact the only use of the term in the document.
>> (And see earlier for my allergy with "trusted":-)
>> 
>>> As an aside, we do have a TLS-like keying protocol for use cases
>>> that involve two-party exchanges - take a look at 
>>> https://tools.ietf.org/id/draft-wood-icnrg-ccnxkeyexchange-01.html
>>> if you’re interested.
>> 
>> No time today sorry;-)
>> 
>>> 
>>>> - 3.7: all the "... confidentiality" paragraphs - this seems
>>>> like it'd be better omitted given the utter lack of ways in
>>>> which such a service can be provided as part of an ICN.
>>> about the protocols the terms apply to not having
>>> confidentiality machinery built in. Would it be acceptable to add
>>> to each of these a statement that the CCNx and NDN layer 3
>>> protocols do not provide such confidentiality and it expected
>>> that higher layers provide such?
>> 
>> I guess. OTOH, defining terms for things-not-done seems odd to me.
>> To give an example, if there were some (higher layer) scheme for
>> confidentiality for interests and payloads that might well require
>> two signatures (one on plaintext one on ciphertext) or some other
>> new concept that isn't the same as data authenticity as defined
>> here, so I'm not sure it's useful to define these terms here.
>> 
> Sure, but your help in improving the document is very much
> appreciated. It’s had a long gestation period, so a bit longer if it
> results in a better result is perfectly ok.
> 
> DaveO.
> 
>> Cheers, S.
>> 
>>> 
>>> 
>>> 
>>> DaveO
>>> 
>>> 
>>> _______________________________________________ icnrg mailing
>>> list [email-masked] https://www.irtf.org/mailman/listinfo/icnrg
>>>