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

[Stephen Farrell <[e-mail]>]

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.
> 
> Thanks again for your time and effort on this!

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:-)

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

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.

> 
>> 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:-)

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

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

> 
>> - 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?)

> 
>> 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:-)

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

> 
>> - 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:-)

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

> 
>> - 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?

> 
>> - 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:-)

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

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

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

Grand.

> 
>> - 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? 

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