Re: [icnrg] Updates to the ICNRG Terminology Document: draft-irtf-icnrg-terminology

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

On 17 Jan 2020, at 22:08, Benjamin Kaduk wrote:

> My MUA's quoting style doesn't seem to interact very well with your 
> MUA's
> quoting style; my apologies if I inadvertently missed something.
> (inline)
>
[snipping to the only remaining item]:

>> Nonce:”A field of an Interest packet that transiently names an
>> Interest instance (instance of Interest for a given name).  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].” RFC 4949 does not have a definition for "cryptographic
>> nonce", so I assume just the regular definition for "nonce" is the
>> intended reference. The only required attribute there is "random or
>> non-repeating", with liveness
>> guarantee and replay protection being only the "usual usage" (i.e., 
>> not
>> required). While I assume I don't fully understand the nuance of 
>> ICNRG
>> nonce usage, my understanding is that they are intended to be
>> non-repeating, at least within some time window, and serve to tie
>> specific expressions of interest to data responses. That is not 
>> exactly
>> the "replay protection" of RFC 4949, though it is closely related, 
>> and I
>> would argue that even the "non-repeating within a time window" 
>> property
>> suffices to keep the ICN usage within the RFC 4949 definition. Which 
>> is
>> a long way of saying that I don't think this much disclaimer is 
>> needed.
>>
>> The concern was that NDN is very loose in their nonce requirements. 
>> For
>> example with guessable nonces an attacker could cause some PIT state 
>> to
>> be created by one incoming interest which might inappropriately cause
>> aggregation of interests from a victim that should have been 
>> forwarded.
>> The point about RFC4949 not defining cryptographic nonces is well 
>> taken
>> however. I toned down the disclaimed to “Note: the specification
>> defining nonces in NDN do not necessarily satisfy all the properties 
>> of
>> nonces as discussed in RFC4949”.
>>
>> Is that better?
>
> It's more clear in that it definitely maps to a specific definition in 
> RFC
> 4949.  That said, the RFC 4949 definition does not directly say
> "unguessable" (and in general in IETF documents we do separately note
> whether unpredictability is required), so my recommendation would be a
> phrasing more like "Note: while the specification defining nonces in 
> NDN
> meets the RFC 4949 definition, the term 'nonce' is sometimes also used 
> to
> imply unpredictability, which is not the case for NDN".
>
> However, you don't need to give my recommendation much weight, and I 
> expect
> you've already put a lot more consideration into this than I have.
>
I’d rather not assert that NDN does in fact comply completely with 
RFC4949, since I’m not directly responsible for any of the NDN design 
or current code. Some of the other authors (copied on the email) are, 
and they may wish to weigh in here. In the absence of further guidance, 
my preference is to keep the revised text I put in -08.

Thanks again for you careful consideration of this document!

DaveO.

> -Ben
>