[icnrg] Some initial comments on draft-li-icnrg-km-reqs

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

<Chair hat off>

It is likely useful to have some formal compendium of requirements we 
can measure proposed key management schemes for ICN against, so thanks 
for starting this off by writing a draft. Many of the requirements are 
generic to any key management system, so it might be helpful to try to 
tease out what might be specific to ICN and spend more time on those 
(you do this to some extent but it’s mixed together with the generic 
requirements).

I had a few doubts and questions while reading the draft; perhaps we can 
discuss these as part of the presentation at the meeting, or if you want 
defer to a draft update or email discussion on the list.

- It’s not clear quite what you are getting at when you say in the 
introduction that signatures on data objects are insufficient to protect 
against “unpredictable data retrievals in CCN/NDN” I get that 
signatures in the absence of some kind of trust schema are insufficient, 
but you seem to be suggesting some deeper problems. Is this around cache 
pollution/poisoning? It might help to either defer this to later or be 
more specific up front.

- It’s not clear why authentication “among routers” is needed. Is 
this to secure the routing protocols?

- the “secure registration” requirement is a bit strange, since as 
far as I know there is no way through purely cryptographic “inside the 
system” techniques to accomplish secure binding between a name and a 
real world identity.

- The efficient revocation requirement is easy to state, but really hard 
to achieve in practice. Might we consider something weaker, like 
revocation to work on the timescale of data liveness or better?

- The requirement on key update is stated in a generic kind of way, 
which is not terribly useful in a world where long-lived data objects 
and ephemeral keys don’t co-exist well. I think it would be useful to 
tease this apart a bit and try to come up with something specifically 
targeted at ICN named objects where you don’t have to necessarily 
re-issue data (or possibly not re-encrypt it) when keys roll over.

- This may just be my lack of knowledge, but I didn’t get a firm grasp 
of either requirement R11 or requirement R12.

Thanks and looking forward to a robust discussion of your draft!

DaveO