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

[Stephen Farrell <[e-mail]>]

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.

In particular I wonder if data packet signatures are
really checked or not (with existing s/w) 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.

Detailed comments/suggestions below.

Cheers,
S.

- abstract: is ICN still "novel"?

- 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!
And where can I find sample logs for mismatching interest and data
packet caught via signature failure? Secondly, the idea that it's
fine and dandy that confidentiality doesn't exist within ICN seems
nicely 20th century. 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.

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

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

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

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

- 3.3: If there exists a useful definition of stateful forwarding,
  then why is there not one for stateless forwarding? If there is
not then why is there not just forwarding? In which case, why do we
need an entry in 3.3?

- 3.3: "data packet" ... the "and is directly secured" phrase - is
  that true? (See earlier.)

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

- 3.5: SHA256 probably calls for a reference.

- 3.5: "nonce" - this has a cryptographic definition that is
  perhaps not the same (see RFC4949). Saying that explicitly would
be good.

- 3.7: "data integrity" also protects against deliberate
  modification, as well as corruption.

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

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