Subject: Re: [rrg] Universally unique identifier

From: "Scott Weeks" <[email-masked]>
Date: Wed, 21 Jul 2010 14:19:31 -0700

--- [email-masked] wrote:
From: Toni Stoev <[email-masked]>
On Monday 19 July 2010 at 21:54:29 Scott Weeks sent:
> 
> From the operator community, I would say that in the long run it wouldn't 
> only be security advocates that'd have an issue and global/universal 
> uniqueness of the identifier will have an adverse affect on acceptance 
> of a New Thing.

Scott, it's actually privacy that Tony has pointed out.
So, what would prevent operators from liking universal uniqueness?
--------------------------------------------

I found an email where he explains it much better than I can.

"I think that a fixed, unchangeable, global identifier that is exposed in 
any way is a privacy issue.

Users need a way to be wholly anonymous to the network.  They should be 
able to (privately) arrange their access connectivity and then be able 
to access the network without concerns that they can be identified based 
on their link layer or network layer information.

I have no problems with a cryptographic private key being used as a 
globally unique identifier, as long as users have the ability to have 
multiple keys.  Certainly someone who wants to be anonymous can generate 
a temporary key."

Operators in the commercial area have to satisfy their customers and the lack of privacy will cause concern among customers.  It's already doing so or TOR and things like it wouldn't exist.  I believe this concern will only increase and not decrease over time.  Thus the operators will care as it all drives the bottom line.

scott

----------
----------
----------

---

From: Toni Stoev <[email-masked]>
Date: Thu, 22 Jul 2010 12:33:14 +0300

On Wednesday 21 July 2010 at 18:23:32 Toni Stoev sent:
> On Tuesday 20 July 2010 at 12:36:56 Javier Ubillos sent:
> > In the case where the service would be provided by random sites on the
> > Internet, well, it is already provided for free today, but I don't know
> > how it would scale (or how a business model would work) if all hosts
> > start registering names automatically.
> 
> Many non-mobile service ISPs employ Dynamic DNS too.
> For inter-ISP roaming random/devoted sites are the solution.
> The model is quite analogous to the one with names.

> Operators in the commercial area have to satisfy their customers and the lack of privacy will cause concern among customers.  It's already doing so or TOR and things like it wouldn't exist.  I beli…

Privacy depends on operators' loyalty. But having a choice of identifier providers, we can rely on identity privacy, even having only one connectivity provider.

Regards
Toni

---

From: Klaas Wierenga <[email-masked]>
Date: Thu, 22 Jul 2010 12:05:45 +0200

On 7/22/10 11:33 AM, Toni Stoev wrote:

Toni,

>>> In the case where the service would be provided by random sites
>>> on the Internet, well, it is already provided for free today, but
>>> I don't know how it would scale (or how a business model would
>>> work) if all hosts start registering names automatically.
>>
>> Many non-mobile service ISPs employ Dynamic DNS too. For inter-ISP
>> roaming random/devoted sites are the solution. The model is quite
>> analogous to the one with names.
>
>> Operators in the commercial area have to satisfy their customers
>> and the lack of privacy will cause concern among customers.  It's
>> already doing so or TOR and things like it wouldn't exist.  I
>> believe this concern will only increase and not decrease over time.
>> Thus the operators will care as it all drives the bottom line.
>
> Privacy depends on operators' loyalty. But having a choice of
> identifier providers, we can rely on identity privacy, even having
> only one connectivity provider.

I don't think the latter is very realistic. On the application layer, 
sure, you can have any number of identity providers. But I don't think 
it is likely that you will have a supplier of a network identifier that 
is not your connectivity provider. Sure, I can imagine a world in which 
TOR like companies will emerge that provide some sort of proxy and that 
promise to keep your identity secret, but if you want to do that any any 
significant scale you will run into problems. Let's not create a design 
that forces us 10 years down the road to solve the GUPI-PII (global 
unique persistent identifier - person identifiable information) 
problem...... I am all for incremental design, but having a tight 
coupling between humans and persistent identifiers is asking for trouble 
imo.

Klaas

---

From: Toni Stoev <[email-masked]>
Date: Thu, 22 Jul 2010 14:06:55 +0300

Hi Klaas,

On Thursday 22 July 2010 at 13:05:45 Klaas Wierenga sent:
> is not your connectivity provider.

It would not be compulsory to have one, but if you would have the possibility to choose a remote network identity provider, your privacy would have more of a chance.
And choice is the advantage of the popular dynamic DNS service providers.

> Sure, I can imagine a world in which  

I agree.

Toni

---

From: Javier Ubillos <[email-masked]>
Date: Thu, 22 Jul 2010 22:02:10 +0200

On Thu, 2010-07-22 at 14:06 +0300, Toni Stoev wrote:
> It would not be compulsory to have one, but if you would have the
> possibility to choose a remote network identity provider, your privacy
> would have more of a chance.

Perhaps I'm missing the point, or missunderstanding something.
But isn't this, in the FQDN case, trivial?

Use some dynamic dns service which mapps an arbitrary name to your IP.
Result, no worse than today.

Much as some people prefer to use an DNS server not provided by their
ISP, one may use a name provider that is not their ISP.

a. Register name (FQDN) "secret123.freenameprovier.org".
b. Update my name to my IP.
c. Use your new the ID->Loc association 
d. Unregister the name ,  or just let the name expire.

// Javier

---

From: Toni Stoev <[email-masked]>
Date: Fri, 23 Jul 2010 00:32:20 +0300

On Thursday 22 July 2010 at 23:02:10 Javier Ubillos sent:
> a. Register name (FQDN) "secret123.freenameprovider.org".

You've said it cristal clear, Javier.

The rest is the actual use of the ID->Loc association in sockets and packet headers.

Best regards
Toni