Tyler Close <[EMAIL PROTECTED]> 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://[EMAIL PROTECTED]/ > > 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 [EMAIL PROTECTED]
