Subject: Re: future of identifiers

From: Dick Franks <[email-masked]>
Date: Fri, 1 Nov 2013 19:06:29 +0000

On 30 October 2013 03:44, Phillip Hallam-Baker <[email-masked]> wrote:

> Lets fix email addresses.
>
> http://tools.ietf.org/html/draft-hallambaker-prismproof-key-00
>
>
If Alice and Bob were intent on keeping their long-running secret affair
from the attention of all-seeing NSA traffic analysis, they would need to
encrypt or otherwise obfuscate their email addresses on a per-message
basis. Advertising a public key in LinkedIn or the pages of cryptography
text books does not achieve much.

Dick Franks
________________________

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 1 Nov 2013 19:48:30 +0000

Just a suggestion, but...

it might be a good thing if we were to first identify what needs to be identified.

I think RFC 1992's model of an identifier (a string of some kind that identifies an application API, and moves with the API) makes a lot of sense. Such a thing would, for example, simplify VM motion in data centers. Taking that model into information-centric/name-based networking, one could imagine it being a string that an application uses to identify itself when it expresses interest in a class of data.

If it's something along those lines, I doubt that it's in any character set, and by the way, while it might have a current-set-of-ip-addresses, it's not an IP address or the EID component of one. I could imagine it being almost anything that can be built into a string, and then signed using an 802.1AR certificate or one from another source.

I could imagine law enforcement "expressing interest" in an interesting party's communications. Or the mafia, or the person's spouse. There might be some interesting security angles.

But seriously, I'd suggest we start from first principles before thinking about solutions here. What needs to be identified, and what characteristics does it have?

On Oct 29, 2013, at 7:38 AM, Jari Arkko <[email-masked]> wrote:

> For background, when I visited the ICANN meeting last summer, they were about to launch a set of panels to advice themselves about key topics in coming years. I promised to join one of them, on identifier technology innovation (along with a few other IETFers). The topic for this effort is future evolution of DNS and other identifiers, including relevant security and management aspects. The viewpoint is primarily to look at this from ICANN’s angle, but of course the matter is interesting to us others as well. 
> 
> And perhaps we at the IETF should also understand the same things. Hence this e-mail.
> 
> I have some ideas on what some of these trends might be. But what do the rest of you think? Where is identifier technology going, and what new things are on the horizon? What do we need to do with IDNs? DNSSEC? What will DANE lead to, and how will id-locator split techniques evolve & be deployed? How will applications or users think about identifiers in the future?
> 
> More information at http://www.ietf.org/blog/2013/10/future-identifiers/
> 
> Jari
>

---

From: Larry Masinter <[email-masked]>
Date: Fri, 1 Nov 2013 15:34:36 -0700

Identifiers are just strings (or data structures serialized as strings). As such, they
have no meaning other than as a string of characters or bytes.

What gives an identifier meaning, what imbues it with the property of identifying
something, is the service guarantee of the organization or system that promises
widely accepted authority to tell anyone who asks what the string means, in the
contexts that the string is expected to be used (aka 'resolution' of the identifier.)

The future of "identifier technology" is really the future of identifier resolution
services. 

> it might be a good thing if we were to first identify what needs to be identified.

"Everything" needs to be identified. 

> I think RFC 1992's model of an identifier (a string of some kind that identifies an
> application API, and moves with the API) makes a lot of sense.

For an API to "move" there have to be two APIs, the old one and the new one,
and for someone to believe that the new one is the "same" as the old one, only 
newer. But this is a judgement call, there's nothing intrinsic.

> Such a thing
> would, for example, simplify VM motion in data centers. Taking that model into
> information-centric/name-based networking, one could imagine it being a
> string that an application uses to identify itself when it expresses interest in a
> class of data.

When I imagine that, I also imagine two different APIs that use the
same string, and what authority I would have to look to, in order to
help me decide which one is right.

> If it's something along those lines, I doubt that it's in any character set, and by
> the way, while it might have a current-set-of-ip-addresses, it's not an IP
> address or the EID component of one. I could imagine it being almost anything
> that can be built into a string, and then signed using an 802.1AR certificate or
> one from another source.

Every finite data structure can be serialized. 

> I could imagine law enforcement "expressing interest" in an interesting party's
> communications. Or the mafia, or the person's spouse. There might be some
> interesting security angles.
> 
> But seriously, I'd suggest we start from first principles before thinking about
> solutions here. What needs to be identified, and what characteristics does it
> have?
> 
> > For background, when I visited the ICANN meeting last summer, they were
> about to launch a set of panels to advice themselves about key topics in coming
> years. I promised to join one of them, on identifier technology innovation
> (along with a few other IETFers). The topic for this effort is future evolution of
> DNS and other identifiers, including relevant security and management aspects.
> The viewpoint is primarily to look at this from ICANN's angle, but of course the
> matter is interesting to us others as well.
> >
> > I have some ideas on what some of these trends might be. But what do the
> rest of you think? Where is identifier technology going, and what new things
> are on the horizon? What do we need to do with IDNs? 

One serious problem with IDNs is the incompatibility with IRIs. While the IRI
spec called for %xx-hex encoding the UTF-8 of non-ASCII characters, IDNs
use punycode, thus leading to the unfortunate situation where an IRI processor
has to guess about whether the authority part of an IRI should be converted
to punicode before passing on a URI to a legacy system that doesn't support
IRIs.   One "fix" would be to insist operationally that the percent-hex-encoded
UTF8 transliteration of a Unicode string be accepted equivalently to the
punicode encoding during DNS lookups.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 1 Nov 2013 21:13:40 -0700

> ...

Agreed, of course. This is a key part of the future I wanted to understand. (But not to forget possible evolution of current identifiers or their characteristics.)

Jari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 2 Nov 2013 12:17:37 -0400

On Sat, Nov 2, 2013 at 12:13 AM, Jari Arkko <[email-masked]> wrote:

> > But seriously, I'd suggest we start from first principles before
> thinking about solutions here. What needs to be identified, and what
> characteristics does it have?
>
> Agreed, of course. This is a key part of the future I wanted to
> understand. (But not to forget possible evolution of current identifiers or
> their characteristics.)
>

Everything needs to be identified but the use of the identifier is what
gives it semantics.

Take the following

A) A static document
B) A document that is created dynamically
C) A can of beans
D) A public signature verification key

All can be referred to by a URI form but there are different ways that they
can be referred to. We can refer to a static document by specifying a means
by which it may be retrieved (a URL) or we could specify a digest of the
document which would identify the document uniquely and but not permit
resolution. And of course we can specify the static document by a raw data
string of the document itself.

So these are the basic modalities of data:

1) Raw: The data Itself
2) Descriptor: A description of the data
3) Locator: A description of how the data may be obtained.

[For those into semiotics this is essentially Noth's trichotemy]

A locator can return the data itself or another identifier. So there are
turtles all the way down.

A dynamic document can only be referenced by how to retrieve it or by a
property that it is asserted only the dynamic document will have. For
example, that it will be signed with a particular public key.

A can of beans is interesting in that we can specify the Platonic ideal can
of beans of which this specific can is an example (i.e. the UPC code) or we
can identify one particular can. Which one you want to do depends on the
purpose. If you are buying Heinz Beans imported from the UK in Boston then
the Universal Platonic Code is all you need. If on the other hand you are
tracking down the 6,000 cans of beans recently stollen or a public health
inspector tracking down possibly tainted beans then you care about the
identifier of the specific tin. RFID codes are used to identify specific
tins and that has proved so useful that the RF part of RFID is now an
anachronism, there are RFID barcodes...

[The same is also true of documents but it is not very useful to have an
identifier for 'all PDF documents', instead we consider this to be a
property that a document may have rather than a document]

A can of beans cannot be located by the identifier alone. But if you add
context (e.g. Amazon.com) then you can turn the description into a locator.
We can play the same trick with data. The ni identifier scheme does exactly
that, taking a digest of a document and adding in location context to turn
the descriptor into a locator.

[Here there is a picture with a triangle (hey he filched the recycling
logo!) at the corners are Raw -> [Digest] -> Descriptor -> [Context] ->
Locator -> [Protocol] -> Raw

Public signature keys can be identified in the same way as static
documents: by value, by location or by digest. But what makes them very
different is that they are a document that can be used to create
descriptions of other documents.

So for example, imagine that we all establish a personal master key. We
might then use the personal master key to endorse additional temporary keys
for our personal use from time to time.

If I have a digest of someone's personal master key and some location
context, I can obtain a current use key

There is however a subtle issue with public keys, endorsements only flow in
one direction. If A signs B and I trust A then I can make deductions about
B. But if I trust B and not A, the endorsement tells me nothing.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Nov 2013 20:36:33 -0500

Another set of concerns is raised by the question of whether an identifier
be human readable or not or have implicit semantics.

The reason the DNS is such a hotbed of political intrigue is that there are
names like microsoft.com and there is an expectation that resolving such
identifiers maps to the companies that have been using the names as
trademarks.

Then there is the question of whether the identifier space is open or
closed. There are only 65535 valid IP ports and so assignment or well known
ports has different considerations to assignment of SRV tags which fulfill
the same function.

IP addresses are also identifiers and there are different considerations
for the different parts of the address. An IPv6 address must be globally
unique and the upper 64 bits have to map to some form of routing
information that is unique at a network level.

But another way to look at an IPv6 address is that it is a 64 bit address
and a 96 bit port space.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 6 Nov 2013 01:36:42 +0000

> "Everything" needs to be identified. 

I'm not sure I buy that.

Let me give you an example. Deborah Estrin did some research a number of years ago with the California Division of Forestry, USC/ISI (which is where she was at the time), and UCSB on the use of a randomly distributed sensor network in managing wildfires. The premise was that an airplane might pitch out styrofoam "golf balls" that contained, each, a watch battery, a cheap GPS, a silicon radio that might be able to reach a few hundred meters, and silicon pretty comparable to the inside of a wristwatch. The device, when it landed, would figure out where it was to a level of accuracy on the order of tens of meters and then turn off the GPS. After that, it would periodically wake up, hear statements from its neighbors, and then make a statement. The statement would be of the form "I am located <here>, and I can hear {<list of locations>}." The statement might also include zero or more statements of the form "location <there> is reportedly [no longer] speaking."

In the nature of the case, if the fire ate up a sensor, it would stop commenting, and the fact of its doing so would rattle around the network until it got to someone that cared, such as an application on a PC. But it is not reported as "Larry's favorite golfball isn't speaking". It's "GPS Location XX/YY isn't speaking".

In this context, the locations need to be identified, but not the golf balls (nobody speaks TO them, so they don't need an address).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Nov 2013 21:30:41 -0500

> But another way to look at an IPv6 address is that it is a 64 bit address

64+16 = 80, I can't count.

Point is that if only 64 bits are being routed on the public internet and
the rest are reserved for 'LAN' use, the uses people find for the lower
order bits of the address space may be very different from those the IPv6
designers anticipated.

Ports and local address space are fungible to a degree, if I run out of
ports I can ask for more local addresses.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 5 Nov 2013 18:54:06 -0800

Nice use case, Fred. Hope you got one of those sensors for your
own underbrushes. I am sure though, that if this is deployed by a
government agency, everything has unique identities, just for keeping
the bureaucracy happy with inventory maintenance and re-supply processes.

Would be nice though if the concept of anonymous identy was better
embodies in the IETF architecture.

Cheers
    Toerless

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 6 Nov 2013 07:32:23 +0000

> embodies in the IETF architecture.

Yes. That said, an identity identifies what someone thinks it identifies. Suppose you had a gold wrist band of a particular style; it might be emblematic of you. But suppose that you had gotten it as a member of some group, all of whom received it; while I might think of it as emblematic of you, it would actually only identify a member of that group.

An anonymous identity, I suspect, is indistinguishable from any other identity in type. But it might be something that is advertised as valid but not associated with an individual (suppose we had a PGP key for [email-masked]?) or one that is shared by a set of actors.

---

From: <[email-masked]>
Date: Wed, 6 Nov 2013 10:09:20 +0000

we are the identities we adopt.

For example, some 'ring knockers' choose to wear their military class rings, or varsity grads their college sweatshirts. In London, it's the old school tie that gets you into the East India Club. At that point, the group has been embraced by the persona, and the identity shapes and marks the identified. (But not always willingly; consider tattoos at Auschwitz.)  Inferring external meaning is tricky with signifiiers.

Point being, multiple identiities in networking (IPv4 and IPv6, multihomed, multiple naming authorities, choosing what to conform to) can be expected to be the norm, and the sign of good networking equipment will be the ability to adopt and discard identities as wanted for purpose with guile and grace (and I don't just mean DHCP). We are many; we contain multitudes. Our networking equipment will be the same.

IPv4 flat address space with a single root DNS is liberatingly simple in some respects, but pretty limiting in others. This would have been a discussion for the end2end list of old.

Lloyd Wood
http://sat-net.com/L.Wood/

> Yes. That said, an identity identifies what someone thinks it identifies. Suppose you had a gold wrist band
> of a particular style; it might be emblematic of you. But suppose that you had gotten it as a member of some
> group, all of whom received it; while I might think of it as emblematic of you, it would actually only identify a
> member of that group.