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

[Colin Perkins <[e-mail]>]

Thanks, Stephen. 

It seems that we need some discussion, and potentially a revision to the draft, before this is ready to progress. I’d appreciate it if the authors and RG chairs could take a look at the comments below.

Thanks!
Colin



> On 24 Sep 2019, at 01:59, Stephen Farrell <[e-mail]> 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.
> 
> 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.
> 
> <0x5AB2FAF17B172BEA.asc>_______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg



-- 
Colin Perkins
https://csperkins.org/