Disruptive Telephony

Last Friday's VUC conference call / podcast / hangout provided some interesting updates about the ongoing work at Matrix.org to build services for scalable, distributed and federated collaboration systems as well as some discussion of Wire, the app I've written about here. Guests included Matthew Hodgson and Amandine Le Pape from Matrix.org, as well as the usual cast of characters and a couple of live demonstrations, too.

You can view the episode web page and listen to the show here:

I joined the show about mid-way through and naturally wound up talking about IPv6, the Internet of Things (IoT), ICANN, DNS and other topics.

FYI, some good info about Matrix.org can be found in their FAQ. Back in November 2014, there was also another VUC episode focused around Matrix.org.

It was an enjoyable show and I'd encourage you to give it a listen.

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on Ello;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Can we create a "secure Caller ID" for IP-based communications, a.k.a. voice-over-IP (VoIP)? And specifically for VoIP based on the Session Initiation Protocol (SIP)? Can we create a way to securely identify the origin of a call that can be used to combat robocalling, phishing and telephony denial-of-service (TDOS) attacks?

That is the challenge to be undertaken by the "Secure Telephone Identity Revisited (STIR)" group meeting tomorrow morning, July 30, 2013, at 9:00 am in Berlin, Germany, as part of the 87th meeting of the Internet Engineering Task Force (IETF). The meeting tomorrow is a "Birds Of a Feather (BOF)", which in IETF language is a meeting to determine whether there is sufficient interest to create a formal "working group" to take on a new body of work within the IETF. The proposed "charter" for this new work begins:

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number.

The agenda for tomorrow's STIR meeting begins with a presentation by Henning Schulzrinne, now CTO of the US Federal Communications Commission (FCC) but also a long-time IETF participant and one of the co-authors of the original RFC 3261 specification for SIP. Henning will be laying out the problem statement and there will be a discussion of the proposed scope of the IETF work. He'll be followed by presentations of potential solutions by Jon Peterson, Eric Rescorla and Hadriel Kaplan and then a discussion of the proposed charter and the work to be done. Given the intense debate that has occurred on the STIR mailing list over the past weeks I expect tomorrow's session to be one where some points will receive a great amount of passionate debate and discussion. (If you are interested in listening in or participating remotely in tomorrow's STIR meeting, see the information later in this article.)

Revisiting Previous SIP Identity Work

As some background, the Internet Architecture Board (IAB) laid out some of the challenges to "secure origin identification" in IP-based communication last November and took a very high-level look at the overall issue. Next, in preparation for what became this STIR effort, Jon Peterson, Henning Schulzrinne and Hannes Tschofenig authored a draft problem statement and requirements document.

The "Revisited" part of the group name is a nod to the fact that this whole issue of asserting "identity" has been explored within the SIP community in the past. Way back in 2006, RFC 4474 defined what has been called "SIP Identity" and provided a method for cryptographically signing certain SIP headers to identify the origin of a call. Unfortunately, RFC 4474 turned out not to work well with the way SIP was actually deployed and so usage has been virtually non-existent. An effort to update that document, what is called "RFC4474bis", has also been proposed and some of those ideas may be incorporated into the new proposed work for the STIR group.

There have also been other efforts such as the "P-Asserted-Identity (P-A-I)" defined in RFC 3325. The challenge here, though is that theoretically P-A-I is supposed to be limited to usage within a trusted network, although in practice it may be seen by other networks. There have also been several efforts to define or document identifiers for billing purposes (including my own P-Charge-Info) although these efforts are trying to solve a slightly different problem.

The point here really is that the STIR effort is drawing upon a rich body of "SIP identity" work that dates all the way back to some early drafts in 2002. Much thought has been given to this issue and many of the people involved with STIR have also been involved with earlier efforts and understand well some of the challenges faced by that past work.

An Important Difference

One important difference between STIR and earlier "SIP identity" efforts is that initially the STIR effort is only focused on telephone numbers. The draft charter explicitly states this:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

and later:

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

Previous "identity" work was also undertaken to include a "SIP URI" or "SIP address" and while the ultimate STIR mechanism (or a variant thereof) might also work for SIP URIs, the focus in this initial work is all around securing the origin identification of telephone numbers.

This initial focus makes a great amount of sense given that so much of the SIP traffic today is a result of telecom service providers moving their regular calls to telephone numbers off of the legacy PSTN networks and over to IP networks where they use SIP. Additionally, a great amount of the "problem" traffic seen in VoIP today can be created by attackers who use simple VoIP software to generate their calls to regular telephone numbers.

Remotely Participating In Tomorrow's STIR BOF

If you are interested in participating in the meeting (or at least listening in) on Tuesday, July 30, the meeting will go from 9:00 - 11:30 local time in Berlin, Germany. Berlin is in Central European Summer Time (CEST) which is UTC+2 (and 3:00 am US EDT / midnight US PDT for my friends back in the USA).

You can hear the audio stream at:

• http://ietf87streaming.dnsalias.net/ietf/ietf874.m3u

You can also join the Jabber chat room at:

• xmpp:[email protected]

The slides and other meeting materials can be found at (and note that materials may not be uploaded until shortly before the session and so you may need to refresh your browser):

• http://datatracker.ietf.org/meeting/87/materials.html#stir

Alternatively you can use the "MeetEcho" conferencing system that integrates the audio, the slides and the Jabber chat room at:

• http://www.meetecho.com/ietf87/stir

More information about participately remotely can be found on the IETF 87 Remote Participation page.

To get the most out of the meeting, you'll also want to read these three Internet Drafts that will be part of the solutions being discussed:

• draft-peterson-secure-origin-ps
• draft-rescorla-stir-fallback
• draft-kaplan-stir-cider

.... and be prepared for what should be a LIVELY discussion!

If you are unable to participate remotely, the session will be recorded and you will be able to listen to the archived audio stream, view the Jabber chat logs and also playback the MeetEcho recording.

Getting More Involved

Beyond listening to tomorrow's BOF session, the best way to get involved - either to actively participate or to at least monitor the effort - is to join the STIR mailing list at:

https://www.ietf.org/mailman/listinfo/stir

The list is open to anyone to join. There are no membership or corporate requirements or fees - anyone with an email address may participate.

WARNING! - As can be seen in the list archive, there is currently a large volume of discussion and it will probably continue for some time. If you do join the mailing list you may want to consider setting up rules to sort the STIR email into a folder - or just prepare for the volume to be added to your inbox.

The other way to be involved is to monitor and read the documents that are created for the STIR effort. Newer documents are being created with "stir" in the document name and so they can be easily found at:

http://datatracker.ietf.org/doc/search/?name=stir&activedrafts=on

Other documents that are useful to understand this effort are linked to earlier in this article and can also be found in the text of the proposed STIR charter. After tomorrow's STIR BOF session there will be more information about how the effort will proceed within the IETF. The meeting tomorrow should result, I expect, in the recommendation to go ahead with formally creating a working group and undertaking this work, but we'll see what outcome occurs.

Can a method of secure origin identification for SIP-based VoIP calls be created? Given that basically all telecom traffic is in the process of moving to be based on IP, the need for a secure origin identifier is very clearly here - and many of us do believe we can develop a system that will work in today's environment.

What do you think? Are you ready to join in and help?

---

Update: Added the additional charter text about "Expansion of the authorization mechanism to identities..."

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

We are in the midst of a truly fascinating cultural shift right now:

We are losing the "family identity" that has been the main characteristic of telephony for the past 100 years.

Think about it... the other day we were at an evening event and met a great couple with whom we would like to stay in touch. We exchanged contact info and they, like so many people these days, have "cut the cord" and do not have a traditional landline but instead have individual mobile phones. The result is this:

I can't call the "Smiths" and speak to someone.

Instead I can call "John Smith" or "Jane Smith".

If I have a message I want to get to the family I have no simple way to do that. I can no longer call "the family phone" and leave a message on their answering machine inviting them over to dinner.

Instead I need to call one of the individual phones - and perhaps both to be sure the message gets through, given that cell phones can be lost or need recharging or that sometimes voicemail messages simply don't get through.

And if a young child wants to call a young child at a landline-less home - and the receiving child doesn't yet have their own cell phone - you have to guess which parent the child might be with.

Now, I don't expect this situation to change. Two years ago I wrote at great length about why I was thinking of cutting the cord myself (and then about why I kept my landline). Last year I wrote about the decline in the landline business in North America and while I haven't checked the most recent stats on landline decline, my own anecdotal evidence tells me that the decline is only continuing. I, too, continue to periodically re-assess whether I want to still keep the landline intact.

It's interesting to wonder, though, what this means for the larger fabric of our society. Are there impacts as we remove the "family" identity and focus on our individual identities? How does it change the nature of communication between families? Or does it not really change things at all?

I don't have the answers... this is probably a longer-term research project some graduate student needs to take on. Still, I wonder...

Meanwhile, since I know in one family that one cell phone died and the voicemail is full on the other phone, I guess I'll have to forget about the phone entirely and just send them a message on Facebook... ;-)

---

If you found this post interesting or useful, please consider either subscribing to the RSS feed, following me on Twitter or subscribing to my email newsletter.

---

Would you like to learn more about OpenID and how it can help with your online identity? Last night in the midst of a intense discussion about OpenID in a Skype chat room, I discovered this site- OpenID Explained:

It's a well-done site that clearly and simply lays out the problem OpenID is trying to solve, discusses how you can get an OpenID (and has a great discussion about what to look for in an OpenID provider and things to think about in choosing one), and shows you typically go through the OpenID login process.

It's not a new site.. it seems to have been around for a while... it's just one I hadn't come across in my various writing about OpenID and identity issues (scroll down a bit to get to the OpenID posts).

I particularly liked this graphic, as it so nicely captures the intent of using OpenID to reduce the number of user account info you have to remember (click on the image to go to the page with the full-size version):

The site does need a couple of very minor updates... for instance, the link on the text "over 27,000 OpenID-enabled sites" takes you to a place on a Wikipedia page where whatever list may have been there seems to have been removed. The "Use" page also embeds Simon Willison's much-referenced OpenID tutorial video from 2006, which is a great introduction video - but unfortunately the example site it references is WikiTravel and when I tried logging in there several times with OpenID I was unable to create an account on the site.

Regardless of those minor nits, it's a well-done site and one that is a good resource if you are looking to learn about how OpenID can potentially help you.

---

If you found this post interesting or useful, please consider either subscribing to the RSS feed, following me on Twitter or subscribing to my email newsletter.

---

Is the new ".tel" domain launching today more than just a pretty web interface to DNS? Is it something really unique? Is it a new service that couldn't be easily replicated elsewhere?

In case you haven't been following the subject, a company called Telnic has launched a new top-level DNS domain ".tel" today. Today, December 3rd, is the launch of the "Sunrise" period where companies can (for a high price) obtain the ".tel" domain associated with their trademark.

The point of ".tel", though, is to not just be "yet-another-top-level-domain" but rather to be a global directory of information - with users/companies having control of their own information.

With the first part of the launch happening today there has been predictably been a good bit of coverage in the blogosphere. Danielle Belopotosky had a great piece up on the NY Times Bits blog, Techmeme has a flow of links to stories and I am sure more will be appearing.

I would, though, suggest people wanting to understand the goals of the service go back and listen to our Squawk Box conversation on September 9th with Telnic's Justin Hayward (www.justin.tel). The part about .tel starts at about the 17:50 minute mark of the podcast and literally did go on for about forty minutes. We put poor Justin through a bit of a wringer as he may not have realized he was walking into a conference call that included a bunch of DNS geeks. He presented his vision of how .tel would work and answered the many questions we threw at him. You can also watch the video of Telnic's DEMO Presentation where Justin is obviously pitching the .tel domain to the DEMO audience. (And yes, the Justin in the video is the same one who was on Squawk Box.)

While my friend Jonathan Jensen is quite enthusiastic about the .tel domain, I remain a bit troubled by a few aspects of it. First, though, let's talk about how it works...

---

HOW .TEL WORKS

One of the admittedly cool aspects of the ".tel" domain is it uses the Domain Name System (DNS) to store all of your contact information. I've been working with DNS for probably 15+ years now and have always viewed it as a rather remarkable creation. Ultimately, DNS is simply a massively distributed database system that allows for the easy querying of information on a global scale. I could go on at length about it and always enjoyed the DNS sections of the TCP/IP classes I used to teach because there is so much that you can do with tools like "dig" (or the previous "nslookup" tool) that are interesting (and fun).

But anyway... the reality is that today in general we pretty much only use DNS as a storage mechanism for mapping hostnames to IP addresses. When you entered "www.disruptivetelephony.com" in your browser window or clicked on a link to a URL that had that hostname in it, your local DNS resolver went off and queried DNS servers to find out the IP address for the web server hosting this site. Your browser then sent a HTTP request to that IP address asking for the appropriate page. That's what we primarily use DNS for.

But why not stick other information in the DNS database?

That's the central premise of ".tel". Why not put contact information, favorite URLs, etc. in there?

Now you have always been able to do this (a point I made in the Squawk Box call). There are "TXT" records that you can insert related to your domain. There are "NAPTR" records that are used in ENUM systems to do lookups on phone numbers (they have other uses as well). On one level, there is nothing the Telnic folks are doing that you cannot do already for your own domain (as long as you can edit the DNS records).

Except that Telnic has put up a pretty web interface that lets you easily edit all of these records. No special knowledge required.

I joined Telnic's "beta" program and you can see in the image to the right what my danyork.vip.tel page looks like from the public point-of-view. You can see that I have a telephone number, email addresses, Skype address, and other pieces of information. There's really no limit to the type of information I can put in here. All just various types of numbers, URLs, keywords and other pointers.

Now let's take a look at how this looks in DNS. Here is part of the output of the 'dig' command run against 'danyork.vip.tel':

dyork$ dig @a.dns.vip.tel danyork.vip.tel any
;; ANSWER SECTION:
danyork.vip.tel.        86400   IN      A       195.253.3.235
danyork.vip.tel.        60      IN      TXT     ".tkw" "1" "pa" "" "a1" "52 Probate Street" "tc" "Keene" "sp" "NH" "pc" "03431" "c" "USA"
danyork.vip.tel.        60      IN      TXT     ".tsm" "1" "pddx" "1"
danyork.vip.tel.        60      IN      TXT     "Dan York,  "
danyork.vip.tel.        60      IN      TXT     ".tkw" "1" "bi" "" "o" "Voxeo" "d" "Office of the CTO" "jt" "Director of Emerging Communication Technology"
danyork.vip.tel.        60      IN      LOC     51 31 12.000 N 0 7 48.000 W 0.00m 10m 2m 2m
danyork.vip.tel.        60      IN      NAPTR   100 103 "u" "E2U+x-voice:skype" "!^.*$!skype:danyork!" .
danyork.vip.tel.        60      IN      NAPTR   100 104 "u" "E2U+web:http+x-lbl:Blog" "!^.*$!http://www.disruptivetelephony.com/!" .
danyork.vip.tel.        60      IN      NAPTR   100 105 "u" "E2U+web:http+x-lbl:Employer" "!^.*$!http://www.voxeo.com/!" .
danyork.vip.tel.        60      IN      NAPTR   100 106 "u" "E2U+web:http+x-lbl:Blogs" "!^.*$!http://blogs.voxeo.com/!" .
danyork.vip.tel.        60      IN      NAPTR   100 100 "u" "E2U+voice:tel+x-lbl:Mobile" "!^.*$!tel:+1-407-967-8424!" .
danyork.vip.tel.        60      IN      NAPTR   100 101 "u" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" .
danyork.vip.tel.        60      IN      NAPTR   100 102 "u" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" .
danyork.vip.tel.        3600    IN      NS      c.dns.vip.tel.
danyork.vip.tel.        3600    IN      NS      d.dns.vip.tel.
danyork.vip.tel.        3600    IN      NS      d.dns.vip.tel.
danyork.vip.tel.        3600    IN      NS      a.dns.vip.tel.
danyork.vip.tel.        3600    IN      NS      a.dns.vip.tel.
danyork.vip.tel.        3600    IN      NS      b.dns.vip.tel.
danyork.vip.tel.        3600    IN      NS      c.dns.vip.tel.
danyork.vip.tel.        3600    IN      NS      b.dns.vip.tel.
danyork.vip.tel.        3600    IN      SOA     stealth.nic.tel. hostmaster.nic.tel. 14 10800 3600 2592000 600

You can see in here various TXT records corresponding to information I entered, a LOC record corresponding to where I was listed as being and NAPTR records pointing to various URLs, email addresses and phone numbers.

Now here's a key point - I entered all this information and in theory I control who sees all that information.

All of this information is publicly available because I chose that it would be publicly available. As Justin stated in our Squawk Box episode, users will have the ability to make some information private and available only to "friends" in some sort of social networking way. I say "in theory" only because in the administrative interface they made available to beta participants, I see no way of actually restricting the visibility of the data. Perhaps I missed something, but I'll take them on their word that they will deliver this functionality.

[UPDATE: Telnic has a page on their developer site about privacy and their friending mechanism.]

The admin interface itself is pretty straightforward. You simply add different records for contact information. You can re-order the pieces of information if you want them to appear in a different order. You can enable/disable pieces of information... delete them, etc.

You can also create "folders", which are effectively DNS subdomains. This, to me, is perhaps one of the more intriguing aspects because now I can create domains like "blogs.danyork.vip.tel" and "podcasts.danyork.vip.tel" that show a subset of my overall contact data. I did have to enter it twice if I wanted it to appear in both places, but still... it's a nice feature to have.

All done very simply and easily through Telnic's web interface.

I would note, too, that because .tel is a "sponsored top-level-domain" (see Telnic's contract with ICANN), Telnic has more control over it than there is over a typical TLD. For instance, even though you purchase a .tel domain, you are NOT able to change the "A" record which points a domain to an IP address. What this means is that a ".tel" domain can never point to a website directly. It will always point to Telnic's web interface (where you could, if you wished, simply have one entry that pointed to your web interface). This type of restriction is not true of general TLDs.

---

THE ADVANTAGE OF USING DNS

The beautiful thing about using DNS is that it is fast and that it can be queried from basically any kind of client in any kind of programming language. DNS libraries exist out there for every language ever used in network-connected applications. In the video I referenced earlier, Justin shows an iPhone app that is able to get information from the DNS system far quicker than it probably ever would from standard web queries. This is what DNS was created for.

To help in that, the Telnic folks have created a Developer area and provided some sample applications (including the iPhone one).

---

BUT COULDN'T ANYONE ELSE DO THIS?

In a word...

Yes

There is absolutely nothing stopping me, you, or anyone else from creating a service based on one of our domains that provided a pretty web interface that allowed users to populate DNS with such contact information. I could set up "dir.disruptivetelephony.com", build a web UI, write some code to update DNS and start selling subdomains off of that domain. Justin could have "justin.dir.disruptivetelephony.com"... he could control it, update it, etc.

In fact, there are very few of the arguments I've heard from the Telnic folks that couldn't be equally addressed by someone else on their own domain. However, the Telnic folks do have a couple of advantages going for them:

SIMPLICITY - It's hard to argue with the simplicity of "yourname.tel". Easy to give out. Easy to type in. Easy to use. Beats by a mile the subdomain system I mentioned above.

EXISTING TLD INFRASTRUCTURE - Because they are a top-level-domain, they can make use of all the existing registrar infrastructure that exists to sell domain names. GoDaddy, DomainDirect, DomainPeople and every other domain registrar under the planet can sell these domain names. There's an existing and at this point very well understood process for registering names, paying for them, etc. If I were to set up my own directory system, I'd have to get people to sell the domains for me or sell them myself. I don't have an entire layer of domain sales companies ready to get out there and sell my domains.

THE SPONSORED-TLD RESTRICTIONS - As I mentioned earlier, by virtue of being a "sponsored TLD" the .tel domain has some additional restrictions set up by Telnic specifically around the inability of a domain owner to change the A record and redirect the .tel domain to a website. If you want a ".tel" domain, you have to agree to the terms of use - it's that simple. Proponents of any other TLD could enter into this directory game and aim to compete with Telnic, but they would have to deal with the fact that their TLDs are not locked into pointing to one location for the website.

So the answer is ultimately - anyone could really do this, but the Telnic folks have set themselves up nicely with some advantages.

---

MY PROBLEMS WITH .TEL

So what are my problems with the .tel domain? Well, I guess I have two more technical issues and then some more fundamental issues. First, the technical issues:

BEAUTIFUL TARGET FOR SPAMMERS - The wonderful advantage of DNS is that it is simple and easy for anyone to query. That includes, of course, spammers. So if .tel is successful and people load up the .tel DNS servers with tons of public contact information, what in the world will stop spammers from harvesting all that public information out of the DNS trees? You can see above that it was trivial for me to get all the information associated with "danyork.vip.tel" out of DNS. It's equally trivial for me to write a little script that iterates through potential .tel DNS names, grabs all the info, finds all records that include "mailto" and then emails those people. Or searches on "voice" and calls them....

Unfortunately there's nothing Telnic can really do about this.

Sure, they can throttle requests from certain sources when those sources launch a zillion requests... and then the spammers will just move to using distributed botnets. There's an inherent challenge in putting contact information out in publicly available systems like DNS - anyone can get it.

This is a large part of what has effectively killed any kind of public ENUM systems. ENUM had the same basic idea. Store phone numbers in DNS so that they and their corresponding SIP addresses could be retrieved. Wonderful way to map phone numbers to SIP addresses so that you can bypass the PSTN. However, spammers can do the same thing. One of the tools on the VOIPSA VoIP Security tools list (I forget which one) will do exactly this - issue ENUM queries into DNS and then make SIP calls to any SIP addresses found. Public ENUM is probably irrevocably dead because of this. (ENUM, however, is thriving inside of service provider/carrier networks, though.)

I've seen responses from folks at Telnic about the spam question (such as this one) focusing on the fact that you can choose who sees what and that the private information is protected by encryption. Which is great... but misses the point. The largest reason I can see to use a .tel domain is to get your information out publicly... so why would I then want to hide it?

SINGLE POINT OF FAILURE - The same strength that Telnic has in not being able to modify the DNS A record is also a weakness. Everything goes back to Telnic. I am sure they have spent a huge amount of time on making their system scalable, reliable, etc. But still... if someone out there mounts a large Distributed Denial-of-Service (DDoS) attack from some botnet... the site and service could be taken offline. Now this is true of most all other emerging services today, so Telnic is not alone in this. But it does cause me some concern. (I guess the one counter argument to this is that presumably local registrars would be able to provide authoritative DNS servers for a given .tel domain. In that case it is not all dependent upon Telnic's servers - although you still would be for authority for the root of the .tel domain.)

Those are my technical concerns.

On a more fundamental level, I have some other concerns:

DIRECTORY INFO IN THE HANDS OF A SINGLE COMPANY - It does admittedly bother me to have a single company behind this .tel domain. Yes, I know, everyone enters their own information and it's all stored in the distributed DNS database. I also realize that for someone to build out their website and infrastructure, etc., it takes money... and the expectation that there will be money coming in at the end... that there will be a return on investment.

Don't get me wrong... the folks at Telnic seem to be great and decent folks. They may be. But I just have fundamental issues when a service that would like to be part of our core Internet infrastructure (as our global directory) is owned by a single company.

Those of us who remember the early days of the Internet remember how much we all chafed against Network Solutions' monopoly on domain name registrations (and their ability to charge more and more). We remember the walled gardens of CompuServe, AOL, GENIE, Prodigy, etc. I am still concerned about the new walled gardens of Facebook, MySpace and even Twitter. I am concerned about Skype's walled garden as it becomes increasingly central.

I'm a security guy. I understand the value in distributed systems and diverse environments (while understanding there are also corresponding risks) in ensuring reliability and availability.

The folks at Telnic may be great people... today. But if the service takes off and then they are acquired by someone else who isn't so friendly... what then?

I guess I'd be far more excited and enthusiastic if the global ".tel directory" was being promoted by some nonprofit consortium or academic-led group... (But then again, would they have been as incented to create it in the first place?)

DID IT NEED TO BE SUCH A BLATANT MONEY-GRAB? - Maybe I am just a bit put off, too, by the rather blatant language the Telnic folks use around their launch information. Today is the "Sunrise" period (no real problem with that term) where trademark owners can apply for their name and pay a very high fee to do so. February 3 marks the "Landrush" period (yes, I don't like this one) when anyone can register a .tel domain for a "premium" price and then finally March 24, 2009, represents the general availability when anyone can register a domain at "regular" prices.

On the one hand, I applaud Telnic on their transparency - it undoubtedly will be a "landrush" on February 3 as everyone who doesn't have a trademark but wants in on a new TLD will rush to do so. And there will be X number of domain squatters who will be looking to register any and all domains that were not grabbed by their prominent owners in .com/.net/.org in an attempt to then try to get those folks to buy the domain names from the squatters. It probably will generate a good bit of revenue for the domain registrars... for Telnic... and for their investors. I just guess I wish it weren't so blatant - I guess the whole "landrush" thing bothers me most... just make the domain available at a price for all of us. Ah, well - I can see why they did it.

DO WE REALLY NEED ANOTHER DIRECTORY? - This is not so much of a problem as a general question... I think it's clear to me that we are still trying to sort out how people best find our contact information on the Internet. We've been trying this since we first started moving online and there have been any number of attempts before. (Recall that Yahoo got its start as a directory of web sites in the then very tiny World Wide Web.) We're still not there. Sites like Facebook would like to be that site for us. So would LinkedIn and Plaxo and a zillion others. Plus there's any number of other startups. Plus you can always take out your own domain name and set that up (as I have done). Will Telnic and the .tel folks succeed where others haven't? I don't know.

---

SO WILL I BUY ONE?

So at the end of the day, would I buy a ".tel" domain? I don't know. I think it's an interesting idea and the reality is that yes, I probably would buy "danyork.tel" if by some miracle it is actually available in March... mostly just because I own most of the other "danyork.*" domains already. There are, of course, many other "Dan York"s out there and so perhaps one of them will get this one. Or perhaps some domain squatter will buy that domain after reading of my interest here in the hopes that he/she could milk more money out of me. (Sorry, but NO!) I just don't see that the value shouts out to me enough that I might be willing to join into the "landrush" and pay a premium price.

But even if I bought it, would I use it? I don't know. The potential for spam still seems high to me. We'll have to see what they do to combat it.

---

THE THORNY PROBLEM

In the end, the problem of locating contact information out on the Internet remains a challenging issue... where do you find the best contact info for someone? a Google search? Facebook? LinkedIn? the person's web site? Some other social networking site? Skype's directory?

Telnic's launch of .tel throws another hat into the ring... why not store all that info in DNS? Will .tel be used? Will people accept a new TLD? (Or are they getting fatigued of new TLDs?) Can the Telnic folks address the spam-harvesting issues that have basically killed public ENUM? Or are those inherent problems of using a public system like DNS? Will enough people use it to make it be a valuable database?

I commend the folks at Telnic for stepping into the ring and offering a solution - and I'll certainly be joining in watching what happens.

What do you think? Would you buy one? Or do you think there are other/better solutions?

---

If you enjoyed this post, please consider either subscribing via RSS or following me on Twitter or identi.ca.

Technorati Tags: .tel, telnic, DNS, internet, domains, domainnames, icann

What is OpenID? What are the security issues around it? Should you trust using it? What do you have to be worried about? What are the main security threats to it?

While I've written about OpenID here, I really wanted to understand more about the security issues around OpenID, so I got together with two other members of the Security Round Table, Michael Santarcangelo and Martin McKeay, to explore the issues around OpenID and security to a far greater degree.

We have shared the resulting conversation as a SRT podcast, and have also published as the show notes the large body of links that we accumulated during our preparation for the show.  I'd encourage you to check out the SRT site purely for the links alone, as I think we pulled together one of the more comprehensive lists of links I've seen related to OpenID.

In the end, the three of us came aware quite impressed with the possibilities of OpenID with regard to the specific piece of the identity puzzle that it is aiming to solve.  We hope this podcast helps people understand both the potential benefits as well as a few potential challenges with regard to security and OpenID.  Comments and feedback are very definitely welcome.

Dean Elwood over at VoIPuser.org has taken up the question about Open ID with his post "Why SIP Doesn't Need OpenID".  Dean suggests that the problem really lies between servers:

The problem of identity authentication actually resides in the server to server realm in a peered environment. How does sip.fwd.com know for sure that a peered call request is really coming from sip.voipuser.org?

Good question... and one that Dean believes can be solved through the use of the already-standardized Open Settlement Protocol (OSP).

The conversation continues...

As I continue to explore OpenID, one of my immediate concerns was... how do I choose an identity provider?  And if I do use an identity provider, what happens if they stop providing OpenID services?  Or what if they are bought by someone and I don't like the new owner?

Essentially - how do I create an "abstraction layer" that allows me to maintain control of my identity and not be beholden to the whims or policies (or circumstances) of a provider?

The answer is amazingly easy... just use your own domain name! As explained by Simon Willison, the process merely involves inserting two lines of code into the header of the HTML page at the URL you want to use.  So, for instance, I updated the page for www.danyork.com (which actually gets pointed to a page in a larger website) to have these two added lines:

<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml">
<link rel="openid.delegate" href="http://dyork.livejournal.com/">

That's it.  Now on any website that allows OpenID logins, I simply use the OpenID of "http://www.danyork.com/" and I am briefly redirected to LiveJournal to approve the granting of access to my identity credentials.  Simple and easy.

The beautiful part about this is that I can switch Identity providers any time I like.  I used my LJ account here, but I actually like some of what ClaimID has to offer.  Perhaps I'll use them instead.

The net of it, though, is that it doesn't matter...   to the websites where I login, I login with the danyork.com id and all is good.  Who actually provides the request for the technical OpenID data is a different matter and should be - and is - separate from your actual identity.  Very cool to see... and nice to be able to be in control of my identity!

P.S. And thanks, Simon Willison, for writing up that tutorial... very helpful.

UPDATE: O'Reilly now points over to the post from AOL's John Panzer about this with more details.  It's funny... I read that post yesterday from John, but I don't think the enormity of it sank in until about 5am this morning when I read the post from Fred Stutzman that I reference below.

---

Wow!  Talk about a major boost for OpenID... continuing my OpenID research, I learned from reading Fred Stutzman (also here) that all 63 million users of AOL Instant Messenger can now use their AIM account for OpenID!  Now, I don't actually use my AIM account all that much these days (my IMs of preference are Skype, Jabber and MSN/WLM)[1], but I had to try it out, so I headed over to stickis.com and logged in using my AIM screen name - as shown in the image to the right.  Simple.  Easy.

Okay, that's fairly cool. My OpenID is simply:

http://openid.aol.com/dyorkottawa

Now the only peculiar thing was that I never saw this screen to grant or deny the access to the site.  The only reason I have this screen capture is because I pressed the Back arrow on my browser because I wanted a screen capture of the login page.  In actual operation, once I was logged into the AOL OpenID page I went directly to the stickis.com page... without actually granting the site access to my OpenID.

Hmmmmmmm...

This happened in Firefox 2, so just to verify the issue, I flipped over to IE7 and tried the same procedure.  Again, I was asked for my AIM password and then... bang... I was logged into the site (without seeing the Grant/Deny screen).  Note that I am not running any AIM client on this PC right now.

Now at the second site I tried this at, schtuff.com (a wiki provider that allows OpenId login), I was prompted to Grant/Deny access... but I was apparently already logged in to AOL's OpenID server.  Of course, I can't figure out how to log out of the AOL "Screen Name Service"... I guess I have to close out all my browser windows.    So given that I can't figure out how to log out, I can't replicate this procedure again (sorry, AOL, but I am not going to exit all my browser windows right now)... so I'd be curious to know if anyone else experiences this.  If you get a OpenID login screen, do you then just go right in?

I'm not sure there is a huge issue... I mean, you are going to the site to login... to a certain degree the Grant/Deny screen seems redundant in this instance.  You still have to go through one screen to allow the relying site access to your ID.  And with subsequent sites it seems to do the right thing and pop up the Grant/Deny screen.  Is the skipping of the initial Grant/Deny screen really a security issue?  (if it turns out to be more than just me?)  I don't know yet...

Anyway, kudos to AOL for OpenID-enabling their system... even if there might still be a few bugs to iron out.

This does raise a larger question, too... who do you use as your ID provider?  There's a long list of OpenID providers, but if you use AOL most of the time for IM, might it not make sense to use them as your OpenID provider?  Or do you want the more granular control provided by some of the others?  Where do you establish your online identity?   It shall be an interesting question to continue to ponder.

[1] My AIM name might give a clue as to why I don't use it as well... I took it out during the 5 years we lived in Ottawa, and, well, I've just never gotten around to getting a new one now that left there 1.5 years ago...

I have to blame Aswath.  Back in December, he posted a short piece wondering about the use of OpenID in SIP authentication.  He contacted Jonathan and I in regard to Blue Box and asked for our comments. We discussed it on Blue Box #48 (at 15:50 in the show) and basically said "well, it's interesting, but there's no trust model so we can't see how it would really work".  I had some further brief email exchange with Aswath, and then somewhere in there he came out with his proposal for extending OpenID use into communication systems.  Again he dropped us a note, and again, even with posts like that of phoneboy, I still hadn't gotten over my concern about trust - and we discussed it again in the soon-to-be-issued Blue Box #51, along with a comment from a listener.

But there was something there that kept nagging at the back of my brain... and then as Microsoft announced support for OpenID out at RSA... and then as AOL is talking about their plans...  along with a hundred other smaller indicators... all of it has made me realize that I've needed to "go deeper" on what OpenID is all about and how it works... and how maybe, just maybe, there might be a role for it in VoIP.

I'm not there yet, but I'm definitely in the middle of the deep dive.  I've told Aswath that I'd get him a longer response - and I will - once the journey has gone a bit further.  In the meantime, those of you who want to follow along can watch my del.icio.us trail on openid... it keeps getting longer.

If you have no idea what OpenID is about at all... think about all the websites you go to and all the different usernames and passwords you have.  What if there was a way to have just one identity you could use everywhere?  That's one of the ideas behind OpenID.  Here's some good places to start if you know nothing about it:

• Screencast on how to use OpenID
• Video from ETech 2006 - "Who is the Dick on your site?" by Dick Hardt of Sxip Identity (nice history of identity efforts)

Lots to learn out there...