Subject: [icnrg] draft-irtf-icnrg-flic-01

From: "Mosko, Marc <[email-masked]>" <[email-masked]>
Date: Sat, 8 Jun 2019 07:02:05 +0000

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.

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.

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

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.

Marc

---

From: "David R. Oran" <[email-masked]>
Date: Sat, 08 Jun 2019 08:38:37 -0400

On 8 Jun 2019, at 3:02, Mosko, Marc wrote:

> 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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO