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

[Mark Stapp]

On 3/15/16 12:11 PM, Burke, Jeff wrote:
>
>

[...]

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

hmm - I'm not sure I'm following that. Forward-secure transmission 
initiated by the client ensures that no observer can tell what the 
client did - what it asked for, what the results were - and ensures that 
different clients' activities cannot be correlated together. when you 
say "the producer might not need", are you saying that you think the 
producer would be impaired in some way if we communicated privately? I 
don't get that.

[...]

>>
>> 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 I've been trying to advocate is parity with the existing internet, 
as a baseline. If we can do better in ICN, that'd be great - and it 
would be fine to be spending less time justifying private communication 
and trying to identify some _advantage_ in the ICN architectures, frankly.

In the current internet, an observer could see me query DNS for 
"facebook.com", and then could see the returned A or AAAA records, and 
then could see me initiate a TLS session with one of those destinations. 
DNS aside (or once DPRIVE is widely deployed), some observer could see 
me initiate a TLS session with a destination that could be associated 
with a facebook data center. so ... that's pretty much a wash, to me. 
now, fb is sort of special, because they're so big that they have their 
own DCs. Other applications that use AWS, for example, are somewhat 
obscured, if the DNS query is private. In their cases, the observer just 
sees me initiate TLS with an AWS DC, and they can't readily tell what 
application I'm using.

As I say, I'd like to have ICN be able to do at least as well as IP. I 
can imagine that in fact some applications could do that in some cases. 
Apps running natively on my pc or my phone could in fact know that they 
use some DC/CDN, and could in fact just ... communicate with it using 
ICN messages. That'd represent parity (imo), in terms of what would be 
observable.

and just to be clear: the forward-secure crypto doesn't encrypt the 
name-components in what I've proposed, and in what the ccnx-keyexchange 
draft describes. the name in the messages just routes to an instance of 
the application and carries some session identifier. the names are 
completely ephemeral. the actual communication that the application does 
takes places entirely inside the crypto envelope. what the application 
does in there is ... an application thing.

 > What about cert or key names that may reflect your
 > identity being requested by the service during authentication?

hmm - that's not how TLS/dTLS/ccnx-keyex work. there's an initial 
diffie-hellman round, with no authentication. then the service 
authenticates, before the client offers anything at all. then the client 
may authenticate as part of the crypto, or not. it's very uncommon at 
this time for _individuals_ to be asked to supply proofs during private 
session setup. the 'login' you do to use a service as an individual 
happens inside the crypto envelope, not as part of establishing the 
envelope. but all of the authentication happens inside an ephemeral DH 
envelope, so it's pretty resistant to observation. it can be MITM'd, of 
course, but as I say, only the cert of the service would be available 
there, nothing from the client/individual.


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

that's ... also not really how it works. the service sends me (as a 
client) its cert, or cert chain, or a compressed version if it thinks I 
may already have cached or pinned the cert chain. I (as a client) don't 
have to go looking for it at all - presentation of the proof that the 
service holds a private key that should be trusted is part of the 
private session establishment protocol.

Thanks,
Mark