I'm not `vigorously advocating' anything, just pointing out that your (and bernstein's) pet approach has some glaring flaws which you're glossing over.
Words like 'glaring' are 'vigorous'.
Note that you have yet to present a single use-case where YURLs are awkward, that I haven't been able to solve using *existing* software features. I have yet to even dip into the set of new software features that could be added.
In contrast, you are supporting a solution, DNSSEC that has serious design and deployment problems.
If you weigh the (disputed) UI issues of YURLs against the functionality failures of DNSSEC, I think you have to decide in favour of YURLs. As you said about the UI issue: "This problem is (obviously) soluble". DNSSEC still has outstanding and challenging problems to solve.
In all the above, I need machine identifiers to be both reliable (something YURL and nym offers and DNS doesn't), and human readable (something DNS offers and YURL and nym does not).
When using YURLs, you still use a human memorable namespace, like the DNS. The only difference is that the namespace is local instead of global.
Whatever interface you use to interact with the DNS namespace can be immitated with a local namespace for YURLs. From the user's perspective there need be no perceptible difference between using DNS versus YURLs.
I'm sorry, I just can't take any alternative naming scheme seriously if its solution to complex identifiers is "let the bookmarks handle it".
Boorkmarks are just one way of implementing a local namespace. If you don't like them, choose another mechanism. There are lots of options and no doubt new ones to be discovered. As I said, you can make it so that your local namespace interface is indistinguishable from using a DNS like namespace. It's all just UI issues that can be solved locally.
The obvious implementation burdens extend beyond the web-browser. There are many programs out there which need host names -- ssh, telnet, ftp, my mail reading program (for pop3), etc -- all of which need an extra indirection layer added, plus the infrastructure need to populate it without driving users nuts.
Take a step back and look at the problem to be solved: users need to communicate with their software using human memorable names.
The technical solution you are so vigorously advocating is for all identifiers, in all parts of the system, to be human memorable. Using human memorable identifiers beyond the human-to-computer interface causes difficult security and scaleability problems. These problems can be easily avoided by using self-authenticating identifiers.
Self-authenticating identifiers are easily deployed in existing software. All of the applications you listed already support keyword/alias/bookmark functionality. GUI based ssh and telnet programs typically support a list of shortcuts for establishing a connection. Another poster to this thread showed how to
use a keyword with the command-line version of ssh. FTP is easily used from a WWW browser with bookmarks. Every mail program I have ever used supports aliases for email addresses. Users happily use these features. The indirection layer you are so worried about already exists and is in common use. We're just not fully exploiting the functionality we already have.
More importantly, people often use hostnames gathered from non-electronic sources.
Keywords are again already in common use here. AOL keywords are commonly used in offline advertising.
Sure you can add a new system to translate between such global names and your obfuscated `hostnames' in a secure manner -- but isn't that what DNSSEC is?!?
No, that's not what DNSSEC is. DNSSEC is another instantiation of a PKI hierarchy. PKI does not use self-authenticating identifiers.
Most importantly, keywords form a local namespace, not a global namespace. A global namespace demands a centralized bureaucracy, with all the costs that entails. Why pay for a bureaucracy when you can provide the functionality you need locally?
So take your namespace with you. What's the big deal? You don't abandon all your data when you switch computers, why should you abandon your namespace?
Even if I don't have a path, my future browser could record the key that's used when bookmarking a site.
That would leave you open to an MITM attack. The attacker can intercept that first request and send your browser whatever key it wants. What you need is a way to strongly correlate the request URL to the site's public key.
I've built a protocol for doing just this. Check out YURLs. The site also provides a proof-of-concept WWW browser that can use to surf the WWW with this protocol.
Where exactly does ssh keep bookmarks, for example?
/etc/hosts
We'll wind up inventing another DNS layer on top of the mess just to get back sensible names.
But that layer could be a locally managed namespace instead of a globally managed namespace. Why should everyone use the same mnemonic to refer to a given site? A global namespace means centralized bureaucracy, like IANA. A local namespace is just as convenient for the user, but creates no dictators.
Your issue is easily handled by the bookmark file keywords provided by Mozilla Firebird. After you've bookmarked a page, you can return to it by typing in your personally chosen keyword.
It is interesting how this simple user interface feature provides a function you thought could only be provided by a central bureaucracy like the DNS. Hold off on the hyperbole a bit. There are some good solutions if you look.
I've worked through a lot of these issues with my YURL work.
Since you're willing to give Bernstein's solution a fair hearing, I suggest you also check out YURLs. There's even a simple proof-of-concept WWW browser that you can use to get a feel for how the WWW without DNS works.
Note that switching to decentralized authentication doesn't mean giving up on human memorable names, just global human memorable names. Users can still use a local namespace. This provides both useability and security benefits. See the YURL Name paper.
Droplets(TM) is a capability environment for web based applications. Most of it is covered by the Mozilla license.
On the waterken.com site, you'll find a running demonstration application and tutorial, as well as a live shopping cart application for making purchases using e-gold.
The Droplets(TM) environment includes an open source interface to the e-gold Shopping Cart API, so that anyone can quickly setup a web storefront.
Slashdot Mirror
I'm not `vigorously advocating' anything, just pointing out that your (and bernstein's) pet approach has some glaring flaws which you're glossing over.
Words like 'glaring' are 'vigorous'.
Note that you have yet to present a single use-case where YURLs are awkward, that I haven't been able to solve using *existing* software features. I have yet to even dip into the set of new software features that could be added.
In contrast, you are supporting a solution, DNSSEC that has serious design and deployment problems.
If you weigh the (disputed) UI issues of YURLs against the functionality failures of DNSSEC, I think you have to decide in favour of YURLs. As you said about the UI issue: "This problem is (obviously) soluble". DNSSEC still has outstanding and challenging problems to solve.
In all the above, I need machine identifiers to be both reliable (something YURL and nym offers and DNS doesn't), and human readable (something DNS offers and YURL and nym does not).
When using YURLs, you still use a human memorable namespace, like the DNS. The only difference is that the namespace is local instead of global. Whatever interface you use to interact with the DNS namespace can be immitated with a local namespace for YURLs. From the user's perspective there need be no perceptible difference between using DNS versus YURLs.
I'm sorry, I just can't take any alternative naming scheme seriously if its solution to complex identifiers is "let the bookmarks handle it".
Boorkmarks are just one way of implementing a local namespace. If you don't like them, choose another mechanism. There are lots of options and no doubt new ones to be discovered. As I said, you can make it so that your local namespace interface is indistinguishable from using a DNS like namespace. It's all just UI issues that can be solved locally.
For more on this, take a look at another post I wrote for this thread.
The obvious implementation burdens extend beyond the web-browser. There are many programs out there which need host names -- ssh, telnet, ftp, my mail reading program (for pop3), etc -- all of which need an extra indirection layer added, plus the infrastructure need to populate it without driving users nuts.
Take a step back and look at the problem to be solved: users need to communicate with their software using human memorable names.
The technical solution you are so vigorously advocating is for all identifiers, in all parts of the system, to be human memorable. Using human memorable identifiers beyond the human-to-computer interface causes difficult security and scaleability problems. These problems can be easily avoided by using self-authenticating identifiers.
Self-authenticating identifiers are easily deployed in existing software. All of the applications you listed already support keyword/alias/bookmark functionality. GUI based ssh and telnet programs typically support a list of shortcuts for establishing a connection. Another poster to this thread showed how to use a keyword with the command-line version of ssh. FTP is easily used from a WWW browser with bookmarks. Every mail program I have ever used supports aliases for email addresses. Users happily use these features. The indirection layer you are so worried about already exists and is in common use. We're just not fully exploiting the functionality we already have.
More importantly, people often use hostnames gathered from non-electronic sources.
Keywords are again already in common use here. AOL keywords are commonly used in offline advertising.
Sure you can add a new system to translate between such global names and your obfuscated `hostnames' in a secure manner -- but isn't that what DNSSEC is?!?
No, that's not what DNSSEC is. DNSSEC is another instantiation of a PKI hierarchy. PKI does not use self-authenticating identifiers.
Most importantly, keywords form a local namespace, not a global namespace. A global namespace demands a centralized bureaucracy, with all the costs that entails. Why pay for a bureaucracy when you can provide the functionality you need locally?
So take your namespace with you. What's the big deal? You don't abandon all your data when you switch computers, why should you abandon your namespace?
Even if I don't have a path, my future browser could record the key that's used when bookmarking a site.
That would leave you open to an MITM attack. The attacker can intercept that first request and send your browser whatever key it wants. What you need is a way to strongly correlate the request URL to the site's public key.
I've built a protocol for doing just this. Check out YURLs. The site also provides a proof-of-concept WWW browser that can use to surf the WWW with this protocol.
Where exactly does ssh keep bookmarks, for example?
We'll wind up inventing another DNS layer on top of the mess just to get back sensible names.
But that layer could be a locally managed namespace instead of a globally managed namespace. Why should everyone use the same mnemonic to refer to a given site? A global namespace means centralized bureaucracy, like IANA. A local namespace is just as convenient for the user, but creates no dictators.
See YURLs.
Your issue is easily handled by the bookmark file keywords provided by Mozilla Firebird. After you've bookmarked a page, you can return to it by typing in your personally chosen keyword.
It is interesting how this simple user interface feature provides a function you thought could only be provided by a central bureaucracy like the DNS. Hold off on the hyperbole a bit. There are some good solutions if you look.
I've worked through a lot of these issues with my YURL work.
Since you're willing to give Bernstein's solution a fair hearing, I suggest you also check out YURLs. There's even a simple proof-of-concept WWW browser that you can use to get a feel for how the WWW without DNS works.
Note that switching to decentralized authentication doesn't mean giving up on human memorable names, just global human memorable names. Users can still use a local namespace. This provides both useability and security benefits. See the YURL Name paper.
TylerDroplets(TM) is a capability environment for web based applications. Most of it is covered by the Mozilla license.
On the waterken.com site, you'll find a running demonstration application and tutorial, as well as a live shopping cart application for making purchases using e-gold.
The Droplets(TM) environment includes an open source interface to the e-gold Shopping Cart API, so that anyone can quickly setup a web storefront.