[Ndn-interest] NDN protocol principles: no privacy?
Mark Stapp
mjs at cisco.com
Tue Mar 15 12:06:24 PDT 2016
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
More information about the Ndn-interest
mailing list