Subject: Re: [icnrg] ICN NRS, DNS etc

From: Ken Calvert <[email-masked]>
Date: Fri, 8 Apr 2016 12:13:36 -0400

Hi Mark -

[Please forgive me if I miss something and this is a stupid question; I wasn't at the meeting and I'm not up on all the latest CCN drafts.]

What is the difference in exposing intentions, activities etc. to the NRS vs. to the global network infrastructure (which will carry your packets)?

I agree with your comments about needing to establish a trust relationship with an NRS. But it seems to me they also apply to the network infrastructure in any ICN-type network, in which interests carry names.

Is your point simply that needing only one such relationship is better than two?  Has a solution for establishing a network-layer trust relationship been elaborated (starting from a point where interests carry names in the clear)?

Ken Calvert

> From: Mark Stapp <[email-masked]>
> Subject: [icnrg] ICN NRS, DNS, and privacy considerations
> Date: 7 April 2016 at 15:24:18 EDT
> To: "[email-masked]" <[email-masked]>
> 
> 
> I didn't want to hijack Marc Mosko's thread about the NRS topic, but since he's raised the parallels with DNS, I wanted to ask about the potential privacy issues with an NRS.
> 
> If I use a service on the network, an application, for example, I can have a trust relationship - via a cert chain, or via a burned-in cert - that can authenticate an instance of that application to me. That helps me, because I can avoid exposing anything about myself - my login credentials, my account name, my email address - or about my activities until the application has authenticated itself to me.
> 
> Adding a naming service introduces a new set of trust relationships, and a new set of privacy concerns. If I am using a name-resolution service in order to access some application on the internet, then either
> 
> a) I expose my intentions, my activities, in the clear to a naming service that I have no trust relationship with.
> 
> b) I develop a trust relationship with some provider of the naming service, I trust that service with information about my activities, and I have some way to authenticate the specific naming service provider before offering any information, just as I would authenticate any other application.
> 
> Choice (a) is obviously a problem. It's true that DNS has largely worked in the clear for a long time, but that's changing now, as a result of the increased ietf focus on exposure of internet users' activities - see the DPRIVE working group. In order to have parity, at a minimum, with the IP world, I think you'll have to explain the potential risks to users of adding a resolution service. And if that service is recursive and distributed, you'll have to explain how a trustworthy set of relationships within the resolution service itself would work so that users are protected.
> 
> Apologies in advance if these questions have already been raised...
> 
> Thanks,
> Mark
>

---

From: Mark Stapp <[email-masked]>
Date: Fri, 8 Apr 2016 13:40:02 -0400

Hi Ken,
not stupid at all - as always, you're looking right at a crucial point.

exposing your activities in the clear is not a good idea. you do less 
and less of it now, on the IP internet. it doesn't make sense to me to 
think that you will want to go _back_ at some time in the future. the 
ietf in general has proposed that passive observation of in-the-clear 
user activity represents a problem, and that the best means of 
countering that is to encrypt communication by default, using 
forward-secret keys and the crypto tools that are current best-practice.

at the moment, I'm sort of outside the icn mainstream, which still seems 
to be

a) it will be ok to communicate in the clear
b) for some special cases, communication might use long-lived, 
non-forward-secret techniques, like asymmetric pairs or group keys. 
these hide some details, but allow correlation.

but I have been asking sort of (to me) obvious questions: why shouldn't 
icn at least be at parity with the existing internet in terms of 
privacy? why do we think that there will be a successful "new" 
architecture that requires removal of privacy and the use of observation 
in order to function?

I don't think the clock is going to be going backwards in this area, so 
I'm interested in the implications. what makes some sense to me is that 
there's value in the icn idea of removing endpoint addresses. since 
those are hard for people to use, they required name-resolution, and so 
that can be removed too. what we really _do_ is use services on the 
network, and with ICN we can use them by name. that actually matches 
reality pretty well: I don't have any idea what the addresses of the 
actual servers I use is - they're in data centers all over the world, 
behind load-balancers and tls terminators. but there's a lot of 
convolution in the IP world to get me to a service endpoint, because I 
have to use IP addressing and routing, and so I often have to be tricked 
(with dns) into using the "right" IP destination.

but many of the security and privacy concepts that are 'current' are 
still applicable to ICN. I don't want passive observers to "see" what 
I'm doing, so I want to communicate with services inside crypto 
envelopes. I want those to be forward-secret, so the compromise of one 
key only compromises a small amount of my activity. that means I have to 
interact with a service endpoint to develop ephemeral keys. further, I 
don't want to be man-in-the-middled, so I want the service to 
authenticate to me before I expose anything about myself - my identity, 
my activities. and again, for many useful services, I expect to need to 
authenticate to the service, so that it can impose access controls and 
so forth.

that, to me, makes some sense. the evolution has been that I don't care 
about destination addresses - I haven't cared about them, really, for 
years - I care about services. name routing and multi-dest, multi-path 
routing would eliminate the need for name resolution tricks. and my 
devices have changed: not having to deal with source addresses (through 
stateful forwarding) helps me with mobility, with multi-homing. but I 
don't think I will be offering up all of my activity in the clear.

so that's a long-winded way of getting to the question about 
name-resolution. if someone's going to propose yet-another way to expose 
my activities to an untrusted, unauthenticated entity, in the clear, I 
sort of want to ask "why"?

Thanks,
Mark

On 4/8/16 12:13 PM, Ken Calvert wrote:
> Hi Mark -
>
> [Please forgive me if I miss something and this is a stupid question; I
> wasn't at the meeting and I'm not up on all the latest CCN drafts.]
>
> What is the difference in exposing intentions, activities etc. to the
> NRS vs. to the global network infrastructure (which will carry your
> packets)?
>
> I agree with your comments about needing to establish a trust
> relationship with an NRS. But it seems to me they also apply to the
> network infrastructure in any ICN-type network, in which interests carry
> names.
>
> Is your point simply that needing only one such relationship is better
> than two?  Has a solution for establishing a network-layer trust
> relationship been elaborated (starting from a point where interests
> carry names in the clear)?
>
> Ken Calvert
>
>> *From:*Mark Stapp <[email-masked] <mailto:[email-masked]>>
>> *Subject:**[icnrg] ICN NRS, DNS, and privacy considerations*
>> *Date:*7 April 2016 at 15:24:18 EDT
>> *To:*"[email-masked] <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>
>>
>>
>> I didn't want to hijack Marc Mosko's thread about the NRS topic, but
>> since he's raised the parallels with DNS, I wanted to ask about the
>> potential privacy issues with an NRS.
>>
>> If I use a service on the network, an application, for example, I can
>> have a trust relationship - via a cert chain, or via a burned-in cert
>> - that can authenticate an instance of that application to me. That
>> helps me, because I can avoid exposing anything about myself - my
>> login credentials, my account name, my email address - or about my
>> activities until the application has authenticated itself to me.
>>
>> Adding a naming service introduces a new set of trust relationships,
>> and a new set of privacy concerns. If I am using a name-resolution
>> service in order to access some application on the internet, then either
>>
>> a) I expose my intentions, my activities, in the clear to a naming
>> service that I have no trust relationship with.
>>
>> b) I develop a trust relationship with some provider of the naming
>> service, I trust that service with information about my activities,
>> and I have some way to authenticate the specific naming service
>> provider before offering any information, just as I would authenticate
>> any other application.
>>
>> Choice (a) is obviously a problem. It's true that DNS has largely
>> worked in the clear for a long time, but that's changing now, as a
>> result of the increased ietf focus on exposure of internet users'
>> activities - see the DPRIVE working group. In order to have parity, at
>> a minimum, with the IP world, I think you'll have to explain the
>> potential risks to users of adding a resolution service. And if that
>> service is recursive and distributed, you'll have to explain how a
>> trustworthy set of relationships within the resolution service itself
>> would work so that users are protected.
>>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>