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

Burke, Jeff jburke at remap.UCLA.edu
Tue Mar 15 09:11:07 PDT 2016






-----Original Message-----
From: Mark Stapp <mjs at cisco.com>
Date: Monday, March 14, 2016 at 12:10 PM
To: Jeff Burke <jburke at remap.ucla.edu>, GTS <gts at ics.uci.edu>, UCLA NDN List <ndn-interest at lists.cs.ucla.edu>
Subject: Re: [Ndn-interest] NDN protocol principles: no privacy?

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

Ok. 

>
>>> 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"?


I was trying to distinguish between data the producer would like to keep confidential vs. requests and responses (e.g., identified by name only) that the consumer would like to keep confidential.  Seems like there are some cases where the producer might not need to keep data confidential but the consumer might not want anyone to know they requested it, for example Wikipedia, or pubmed, or any government data in public record.  Your example cases are often where both the consumer and producer desire data to be confidential (e.g., your bank data), but this is not the only case. 


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

So in this case you are ok with requests to service names that reflect a plaintext prefix (/com/facebook) but have further components encrypted by ephemeral keys?   What about cert or key names that may reflect your identity being requested by the service during authentication?    If "in-network discovery" was used to find a sufficiently current version of the certs in the authentication phase of this scenario, would that be objectionable? Just trying to understand the limits here.

thanks,

Jeff




>
>Thanks,
>Mark




More information about the Ndn-interest mailing list