Announcing httpsy://, a YURL scheme

[Perry E. Metzger]

Tyler Close <tyler at waterken.com> writes:
> On Wednesday 16 July 2003 11:26, Perry E. Metzger wrote:
> > It seems to me to be more "a bad idea, fully realized".
> 
> Perry, throughout this thread, you have made a number of factually
> incorrect statements about YURL.

I believe my statements are reasonable.

> Never have you provided an argument to backup any of these
> statements.

I have. I explained them in modest detail, which seems
sufficient. That's more than you've done -- you have no security model
explained in any level of detail, even a modest one. I think you've
got something of an obligation to at least explain your security model
instead of pointing us at a web page that spends half its space
explaining the sociologist who originated the style of diagrams you
use.

> > I'll repeat:
> >
> > 1) The "YURL" makes key management and replacement effectively
> >    impossible.
> 
> False.
> 
> YURL makes key management *much* easier than it is under the PKI.
> See:
> 
> http://www.waterken.com/dev/YURL/Why/#Certificate_lifecycle_control

That page says nothing of any interest at all. It is two fluffy
paragraphs that do not address what I think of as real key management
issues -- such has secure transmission of keys and replacement of
compromised keys, i.e. what a professional in this field would call
"key management". I encourage others to read these paragraphs and
judge for themselves.

One wonders, of course, why you couldn't have simply forwarded those
two paragraphs rather than referencing them.

I will again repeat my argument. Users will bookmark YURLs or
otherwise save them, making it impossible to change said YURLs in
practice, and thus making it impossible to change keys. In any case,
the system effectively requires manual, out of band intervention to
handle key changes and distribution, making it effectively
impractical.

> The HTTPSY specification states that:

I've read the documents. They are unenlightening. The fact is, you
can't change keys and users can't remember your YURLs.

> For example, the YURL for the Waterken Inc. site is:
> 
> httpsy://r4wdwfrp37ii6qzjlyklkeacbe@waterken.com/
> 
> The private key corresponding to this public key hash has never
> existed on the Waterken Inc. server.

You prove my point: you can't change keys. Someone bookmarks that
incomprehensible gobbledygook because they can't possibly type it from
memory, and that's it -- you're frozen. As I said:

   The "YURL" makes key management and replacement effectively impossible.

> I am actually practicing what I preach in the "Why use YURLs?"
> document. Read it.

I read it. I'll be blunt: it is poorly written, amateurish work and
addresses none of the concerns I have. Your site is full of long,
fluffy documents, and contains not so much as a paragraph of
professionally written threat analysis. Your whole site could be
written in a much more concise document a fraction of the space -- but
sadly that would still leave out the threat model.

One more comment: just because you've learned how to include lots of
document references and speak in an academic style doesn't mean there
is any content. Or, to put it another way, try reading the chapter on
"Cargo Cult Science" from Feynman's "Surely You Must Be Joking,
Mr. Feynman". The appearance of academic rigor and actual rigor are
totally different things.

> > 2) It leads to situations in which you have no way to know what sort
> >    of trust relationship you have for the documents you're looking at.
> 
> Garbage.

Sigh.

> You always know how you got the YURL, because someone has to send
> it to you and you have to receive it. At the very least, you know
> how you got the YURL. This establishes your initial trust
> relationship.

I'll repeat my trivial example. I click on site A. It gives me a link
to site B. It gives me a link to site C, and I go on further to D, and
E, and F. By the time I'm at the end of a chain of these, I've got no
idea in practice who I trusted or why. Dozens of people could silently
be in my trust path. I won't even remember why I think a particular
unreadable string gives me any confidence I'm talking to a legitimate
vendor.

None of this gives me anything of use anyway. What a user wants to
know is that he won't be defrauded if he types his Visa number in to a
page (or his bank password or whatever). YURLs don't address that in
the slightest. However, since you have no threat model at all -- only
a long list of web pages you insist I haven't read although I've
combed them for a shred of useful information without success -- there
isn't any way of knowing if YURLs are useful for anything.

> You can then amplify the trust relationship by asking another
> trusted site to vouch for the YURL.

Pretty much worthless. Your mom wants to buy books on Amazon, not to
try to decipher the meaning of a long sequence of worthless letters. I
assure you that my mom isn't going to deal with even the simplest of
the schemes you propose.

You make the following bizarre claim on your site:

    Rarely are humans required to memorize a URL

Well, that must mean that virtually all advertising with URLs in it
etc. doesn't exist, then, eh? My mom knows "www.amazon.com" -- she has
it memorized. Funny, ain't it?. My remembering that "www.verizon.com"
is where I pay my phone bill must be imaginary, too. My girlfriend
seems to remember the URL for her webmail account, but I doubt she'll
be able to type in the YURL for it.

> These principles are explained in the YURL Definition,

Again with your documents. Repeating: they do not answer the questions
you claim they answer.

> > 3) It is impossible for people to determine that a "YURL" actually is
> >    what it claims it is, given that most people can't actually
> >    remember one hash, let alone large numbers of them, etc.
> 
> I can make no sense of this statement.

I'm not surprised.

> First, a YURL doesn't claim to be anything. No URL does.

On the contrary. When I as a user I type in "www.amazon.com", I'm
expecting to be speaking to Amazon, a merchant that I trust, and not
Joe's Random Con Game, who I don't trust with my credit information.

A "YURL" doesn't help me with that. I can't read a "YURL" off the side
of a bus and remember it, and if it were possible for me to the site
could never change its keys!

CAs are flawed, but they do serve the function of saying that at least
someone who's widely known attests that I'm connecting to the right place.

Or, as *you yourself* say:

   "If your URLs must be human memorable, the PKI is an appropriate
   choice for authentication."

i.e. YURLs don't help.

> No one is being asked to remember any hashes. This has been
> pointed out to you multiple times, by multiple different posters.
> This is the whole point of the YURL Trust Management document.

I've read your documents already, and I stand by what I said. In
practice, a user gains nothing from this other than being forced to
decide if they believe a meaningless sequence of digits and letters
has some correspondence with what they've used in the past.

> However, if you insist on calling my work vomit, then I will defend
> my work with equal zeal.

How about just posting an actual, professionally written threat model,
eh? Because right now, you don't have one. Another hint is that rather
than posting URLs to documents that introduce use to "Granovetter
Diagrams", you could just post a couple of paragraphs with a nice,
clean, professionally written threat model.

Perry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com