Re: [icnrg] draft-irtf-icnrg-flic-01
"David R. Oran" <daveoran@orandom.net> Sat, 08 June 2019 12:39 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 8039D120018 for <icnrg@ietfa.amsl.com>; Sat, 8 Jun 2019 05:39:15 -0700 (PDT)
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 IVxOr8lZ7p9y for <icnrg@ietfa.amsl.com>; Sat, 8 Jun 2019 05:39:13 -0700 (PDT)
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 5B3621200A1 for <icnrg@irtf.org>; Sat, 8 Jun 2019 05:39:13 -0700 (PDT)
Received: from [192.168.171.1] ([IPv6:2601:184:4081:19c1:652a:17cb:f56e:f654]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id x58Cd9jq001475 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Jun 2019 05:39:11 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: "Mosko, Marc" <mmosko@parc.com>
Cc: icnrg <icnrg@irtf.org>
Date: Sat, 08 Jun 2019 08:38:37 -0400
X-Mailer: MailMate (1.12.5r5635)
Message-ID: <FF68F94D-B3F2-43CE-B7F5-3C890CEFBD9C@orandom.net>
In-Reply-To: <BYAPR15MB3272B93AAB12CCC1C6FBA817AD110@BYAPR15MB3272.namprd15.prod.outlook.com>
References: <BYAPR15MB3272B93AAB12CCC1C6FBA817AD110@BYAPR15MB3272.namprd15.prod.outlook.com>
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/Xpdro7j9h3kGZ-Lkfd3QtOUMbGc>
Subject: Re: [icnrg] draft-irtf-icnrg-flic-01
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, 08 Jun 2019 12:39:16 -0000
On 8 Jun 2019, at 3:02, Mosko, Marc wrote: > All, > > I will work with Christian and Chris to finish the FLIC draft. > > My main technical issue with the draft is there is no way to seek > through a tree. The "OverallByteCount" only applies to child data > nodes, so one does not know how many bytes are contained in a child > manifest (subtree). I assume that one would like to be able to seek > in log time to any position over the tree. > This makes sense, at least for files (I know, the âFâ in FLIC). > It is also not clear if there is anyway to know the total application > file size and application hash for an entire subtree, which I assume > would be useful stuff at the top level of the manifest. > Yes. I also commented earlier that the extensibility model for Manifests needs to be spelled out now, so we can evolve the specification without either starting over or creating hacks (like a new kind a root manifest that contains metadata + a FLIC root Manifest). > Finally, there is the FLIC encryption introduced in the -01 draft. I > think this needs to be greatly expanded and an example or two given. We might want to look at the more recent NDN work on explaining NAC to see what if any effect that approach might have on FLIC manifests (https://users.cs.fiu.edu/~afanasyev/assets/papers/zhang2018nac.pdf) > Do we want to have one draft without encryption and one draft on an > encrypted manifest? Or keep it all as one? What I would lean towards > is one draft with unencrypted FLICs and a second draft with encrypted > FLICs that gives at least one concrete set of algorithms and > procedures for adding and removing users. > I lean the other way, for two reasons: 1) the management overhead for progressing two specifications, when the two are so closely related 2) the political hassle of getting an unencrypted Manifest spec through the security and privacy reviewers. > The draft makes some mention of manifest encryption versus application > data encryption. I am not sure we want to tie those together. FLIC > should be able to assemble an encrypted application payload without > any idea how to decrypt it. > Yes. The FLIC draft should only deal with encrypted Manifests, with the main goal being protecting the privacy of the names/hashes and especially any metadata that gets added to manifests. > Marc > _______________________________________________ > icnrg mailing list > icnrg@irtf.org > https://www.irtf.org/mailman/listinfo/icnrg DaveO
- [icnrg] draft-irtf-icnrg-flic-01 Mosko, Marc <mmosko@parc.com>
- Re: [icnrg] draft-irtf-icnrg-flic-01 David R. Oran