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

[Triezenberg, Bonnie]

Although not all communications are private, it does not follow that a network should be designed such that it is impossible obtain privacy or violates the privacy of communication….  Perhaps the principle is instead the “ability to preserve privacy” of communication.

bonnie



From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Luca Muscariello
Sent: Monday, March 14, 2016 1:00 PM
To: Mark Stapp
Cc: UCLA NDN List
Subject: Re: [Ndn-interest] NDN protocol principles: no privacy?

Imposing that all communications must be private is in contradiction with the principle of universality as long as the network is supposed to carry any kind of application.

So I disagree that privacy is a principle.
Not all communications are private.

Luca



On Monday, 14 March 2016, Mark Stapp <mjs at cisco.com<mailto:mjs at cisco.com>> wrote:
interesting -

On 3/14/16 11:27 AM, Burke, Jeff wrote:

[...]
RFC 6973 takes a nice approach, for example, by offering
definitions of some technical properties and mechanisms, but not trying
to formulate an overall definition of "privacy".

So I can try to understand your point here - do you agree with the
authors that the primary privacy concerns are those of individuals? (Or,
more generally, are corporations people here for this discussion - a
more generic "data owner"?)


hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B?
The editors there say
that the body of the document, the discussion of the tradeoffs and
alternatives, is the best way they could come up with to approach that
abstraction. in practical terms, as you know well I think there's been
an over-reliance on opportunistic caching in ICN generally, and as a
result observability and correlation are defined to be positive
properties of ICN communication rather than harmful ones.


Would I be correct to parse your concerns into two pieces that may
have different implications:

- Confidentiality of request (e.g., the consumer side)
- Confidentiality of publication (e.g., the publisher side)

I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"?

[...]

most of these six "principles" sounded like "mechanisms" to me - the
list felt like the end of a discussion about alternatives and the best
ways to implement an architecture, rather than the start of one. it
sounded like "we're tired of questions about LPM in the PIT, so we're
going to stop calling that a possible mechanism and start calling it an
inevitable, immutable, unquestionable 'principle'".

Well, to take LPM for an example - it's actually not mentioned in
the
principle doc that Alex sent. The principle I suspect that you are
referring to is:

[5] In-Network Name Discovery: Interests should be able use
incomplete
names to retrieve data packets.
A consumer may not know the complete network-level name for data, as
some parts of the name cannot be guessed, computed, or inferred
beforehand. Once initial data is received, naming conventions can help
determine complete names of other related data:


* majority of interests will carry complete names

* in-network name discovery expected to be used to bootstrap
communication)



Can you explain your objection in these terms?

sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service.

Thanks,
Mark
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

__________________________________________________________________________

This email message is for the sole use of the intended recipient(s) and
may contain confidential information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160314/fdbd27ad/attachment.html>