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

Mark Stapp mjs at cisco.com
Tue Mar 15 13:18:55 PDT 2016

>> as long as user activity can be
>> correlated readily, there's an exposure that seems to me to be
>> undesireable - and it's unnecessary, given the technology that exists.
>> the initial point I was trying to make was that it felt (to me) that
>> there was a gap in the list of six because there was no mention of
>> private communication. as I said in an earlier email, even having a
>> broad statement would seem to be desireable.
> I tend to agree with Luca that I'm not sure this would be a
> principle
in the same sense as the others. BUT, I am also really interested in
what might be "application-level" concepts or conventions that would be
just as valuable. So, to me, whether or not it is in the design
principle list doesn't exclude it from discussion or showing up in some
other list.

I ... didn't really expect that the NDN folks would suddenly discover an 
interest in privacy, and add it to their list.


> Some thoughts/questions off of the top of my head:
> - I'm not sure about the notion of a "default". It seems like it
inevitably would devolve to discussion of how often one case versus
another occurs, or the social cost of one case vs. the other, to
determine what the default should be. I like the second articulation
better for that reason, as a goal if not a principle, because it avoids
both the language of "defaults" and specific mechanisms.

the point is that there is a default in NDN - it's currently 
"in-the-clear". that's no longer the best practice for network 
communication - "in-the-clear" makes users vulnerable, and that's 
entirely unnecessary given the technologies we have available.

> - In the first articulation, can ephemeral be made more specific?
> How  long should a key be used?

ephemeral in these terms means negotiated using a diffie-hellman 
exchange - finite-field or elliptic-curve. it means, basically, random 
and uncorrelated with any party to the communication in any way.

symmetric key lifetime - that's really a question for the cryptographers 
in the room? I suspect there's a guideline out there somewhere for 
number of seconds/number of bytes, given a symmetric key of a particular 

> - In your principle, would you object to using only the term
confidentiality over privacy? Seems like this would make it sharper. If
you would object, what does privacy cover that confidentiality doesn't,
that can be achieved within a network architecture?

if I understand the way the security folks use the words, "confidential" 
has a fairly specific meaning:  "keeping data secret from unintended 
listeners" (that's from RFC6973). That RFC spends most of its text 
talking about "privacy", though - which may include a constellation of 
properties, such as authentication, authorization, a range of 
adversaries and vulnerabilities. I think that broader constellation is 
what I mean by "privacy", because different users and applications will 
desire different tradeoffs among the complex of system and communication 

> - Is it possible to articulate confidentiality (or privacy) of what
from whom in such a goal/principle? My primary concern here is that
current "best practice" includes some real limitations and assumptions
(e.g., that once the bits hit the edge of the remote service, things are

I ... don't think that's quite fair. First, many services now continue 
to use TLS internally, and of course many or most encrypt data at rest 
as well. I don't see how the NDN choice to communicate in the clear 
affects what happens inside the service.

> Just riffing on the above two points - I don't find that
> confidential  communication with Facebook to actually do much for my personal privacy.
I do want it to be confidential, but considering just the channel
between my browser and the service is a red herring relative to bigger
issues of privacy and data ownership.

ok ... but you've made the choice to use a service that you know treats 
_you_ as a target. (I don't use it, fwiw.) at least the service can 
apply some access controls among its users, even if it is itself able to 
observe all of your fb activity. you're not saying you'd like to login 
to and use fb without TLS - right? you don't want someone sitting next 
to you learning your password, or gaining access to material that a 
stranger should not see?

the are data ownership, regulatory, and policy issues out there, for 
sure. the use of crypto on the wire is really orthogonal to those - it's 
not a replacement for addressing them. our legal and regulatory systems 
have had a difficult time keeping up with the pace of change in some of 
these areas. but that's not a reason to want to expose your personal 
info in-flight, is it? and if you want to protect your info in-flight, 
there are technologies to do that and they're available - and they are 
the default for IP.

> In fact, I would prefer that my postings are confidential from
Facebook itself but not my "friends" in their social network - this is
not really the current model of session-based security. I suspect that
NDN can do better at that, revenue model of the service notwithstanding.
(Here, I would like a goal or principles that goes beyond privacy and
has to do with data ownership and control, which drives alternative
service designs and reflects other rights, not just privacy.)

I ... don't know how to respond to that. You've chosen to use a service 
that's not entirely benign. again, that's really orthogonal to the 
techniques used to protect your communication on the internet (or not). 
I understand there's a lot of interest in p2p in NDN. I don't see it 
happening myself, but I'll be interested to see what happens. but I 
think it's a mistake to continue to reject the best-practice techniques 
for communication privacy, and I think it's a mistake to be left behind 
as the internet moves forward.


More information about the Ndn-interest mailing list