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

["David R. Oran" <[e-mail]>]

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.


On 1 Oct 2019, at 10:09, Stephen Farrell wrote:

> Hi Dave,
>
> On 01/10/2019 14:06, David R. Oran wrote:
>> Stephen & IRSG,
>>

>>> 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.
>
> 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.
>>>
>> Good point. We’ll change it to “may be the subject…”
>
> Yep, that's likely better.
>
done.

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

>>
>>> - 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.
>
> 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.
>> 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.
>
I adopted your text. Thanks!

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

>>
>>> - 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.
>
> 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:-)
>
so, we can survive another day. Thanks. No change here.

>>
>>> - 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”.
>
> That's better yes. (And thanks for the clarification, I hadn't
> 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.”

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

>>
>>> - 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.
>
> Fair 'nuff, 'twas a nit:-)
>
Ok, thanks. No change.

>>
>>> - 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.
>
Ok, no change. There are in fact “PIT less” designs, but they are not entirely stateless.

>>
>>> - 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”?
>
> 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?
>>>
>> 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.
>
Thanks. No change then.

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

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

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

>>> - 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?
>
> 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":-)
>
I didn’t make any changes here.

>> 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.
>> 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.
>
I don’t think it hurts to leave them so given you don’t feel strongly, I left things as they are.

> And again, just to re-emphasise - none of the above ought be
> 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.

> Cheers,
> S.
>
>>
>>
>>
>> DaveO
>>
>>
>> _______________________________________________ icnrg mailing list
>> [e-mail] https://www.irtf.org/mailman/listinfo/icnrg
>>
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO