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

"David R. Oran" <daveoran@orandom.net> Sat, 18 January 2020 13:30 UTC

Return-Path: <daveoran@orandom.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5FA120020; Sat, 18 Jan 2020 05:30:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Xpk8wv0xERU; Sat, 18 Jan 2020 05:30:25 -0800 (PST)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B3C12001B; Sat, 18 Jan 2020 05:30:25 -0800 (PST)
Received: from [192.168.2.1] ([IPv6:2601:184:407f:80ce:2cc1:5073:2c95:4105]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 00IDUHxC020632 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Jan 2020 05:30:19 -0800
From: "David R. Oran" <daveoran@orandom.net>
To: "Benjamin Kaduk" <kaduk@mit.edu>
Cc: "Colin Perkins" <csp@csperkins.org>, "Mirja Kuehlewind" <ietf@kuehlewind.net>, ICNRG <icnrg@irtf.org>, draft-irtf-icnrg-terminology@ietf.org
Date: Sat, 18 Jan 2020 08:30:12 -0500
X-Mailer: MailMate (1.13.1r5676)
Message-ID: <E8C181DE-5D11-465A-A013-747205440F87@orandom.net>
In-Reply-To: <20200118030826.GX80030@kduck.mit.edu>
References: <5DA61530-586A-4BE3-9ECA-6F02AE9899CE@orandom.net> <20200118030826.GX80030@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/KmMpuy4CKvqYtoYRRXkKlRZrhpI>
Subject: Re: [icnrg] Updates to the ICNRG Terminology Document: draft-irtf-icnrg-terminology
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jan 2020 13:30:30 -0000

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
>