[Ndn-interest] NDN protocol principles: no privacy?

GTS gts at ics.uci.edu
Mon Mar 14 09:34:01 PDT 2016

See below please:

On 3/14/16 6:20 AM, Mark Stapp wrote:
> .....
> that is a statement I've heard repeated, but the deeds don't align 
> with the words. NDN has encouraged the use of long-lived 
> public/private key pairs, and that makes individuals highly 
> observable, and vulnerable in the case of key compromise. I don't know 
> whether NSF noticed, but ... you can't do your banking with this stuff 
> yet - and it's been years. and since the folks in charge flat-out 
> reject DH negotiation, it's a little hard to see how they're going to 
> come up with any forward-secure approach. just exactly what 
> privacy-by-design feature are you referring to?
I can't speak for NDN as I have no involvement with the project in the 
last few years. But, if I recall correctly,
NSF liked that: (1) interests have no addresses, and (2) neither does 
content. (Yet, both interest and content
clearly point to the producer). As we all know, (1) and (2) are made 
possible by router caches and PIT-s.
Without caching, destination addresses in interests would be 
unavoidable. And, without PIT-s, source
addresses in interests (and destination addresses in content packets) 
would be needed.

Having persistent public keys is indeed a privacy issue. I completely agree.

>> ....
> just pointing out that you began by sort of implying that the 
> principle was already in place - and that NSF had approved of the path 
> NDN has taken. I have heard the words you echoed in your email many 
> times - and so I was pointing out the absence of any privacy or 
> confidentiality 'principle' in the initial list of six.
No, I didn't mean to imply that NDN already adheres to the lofty privacy 
principle. I did mean to say
that it does have some privacy features, commensurate with some privacy 
non-features :-) or problems, i.e.,
I wouldn't call NDN privacy-hostile or privacy-friendly.

> ...
> the issue is that some of the other NDN mechanisms, like 'sync', rely 
> on broadcasting and shared caching. and then that becomes a 
> fundamental basis for ... every other example - the routing protocol, 
> the NDN-RTC scheme, etc.
> and of course (again, as I'm sure you know) the issue isn't that you 
> can't _ask_ unknown routers controlled by unknown parties _not_ to 
> observe you, or capture/record your communication. the issue is that 
> they may act against you anyway. as an individual user, you can only 
> limit what an adversary can do, and using best-practice communication 
> and crypto techniques is one of the best ways we know of to accomplish 
> that.


More information about the Ndn-interest mailing list