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

[Stephen Farrell <[e-mail]>]

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!
> 
> 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
> 
> 
> _______________________________________________ icnrg mailing list 
> [e-mail] https://www.irtf.org/mailman/listinfo/icnrg
>