Ed Gerck wrote: > > >From your URLs: > > "The browser verifies that the fingerprint in the URL matches the public key > provided by the visited site. Certificates and Certificate Authorities are > unnecessary. "
I agree that the last part is a little aggressive. "Unnecessary" is so ... final. What this does is to place the URL as the point of trust, rather than placing a CA at the point of trust. It also, as an aside, allows the CA to remain as a upstream point of trust. (Or, so I read it?) > Spoofing? Man-in-the-middle? Revocation? > > Also, in general, we find that one reference is not enough to induce trust. > Self-references > cannot induce trust, either (Trust me!). I'm not sure whether the intention is to allow filtering of URLs and caching of hashes found therein! That seems the obvious intention; to scatter a thousand URLs out there, and by the time the browser has a desire to upgrade the connection, it has already established a record of hashes. Is that the case, Tyler? > Thus, it is misleading to let the introducer > determine the message target, in what you call the "y-property". Spoofing and > MITM become quite easy to do if you trust an introducer to tell you where to go. Essentially, trust is established at the point of "when you trust this URL, you can trust the connection." That's quite valuable. It separates out the trust into two separate protocols, which makes both much stronger. In fact, I think it is essential for a sound security model. It's what makes SSH so efficient, and it's what makes SOX so simple. Obversely, I suspect, but am not totally convinced yet, that it is at the root of SSL's issues as a protocol. It can be seen by inspection that the second part; booting from the URL to a secured connection, is, on the face of it, viable. How is the URL trusted, is the big question. If the answer is that it is no less trusted than the ordinary http URL, and less trusted than a https URL, than that's still valid, and a vast improvement on today's situation of 99% untrusted browsing. > Not that I believe CAs are essential (I don't, for reasons already presented in '97), > but unless the issues of spoofing, MITM and revocation are adequately handled > according to a threat model that is useful, communication cannot be considered > secure. Well. I worry that your criticism rides on a circular assumption. To unwind, it is a statement of definition that if the threat model is not covered, then the communications are insecure. If the threat model *is* met, then the communications are secure. So the question devolves to "what is the threat model?" 1. Clearly, the threat model does not include MITM. That's quite practical in today's world. See my rants on the subject for my logic. 2. Revocation of a private server key seems an unusual need. Granted, in a PKI of some dynacism (?), this would be a real shortfall. But for a website server, I don't see the need for revocation. It's not as if private keys are stolen anytime, much, and if the server cert changes for operational reasons (end of year, etc), then that moves the YURL into the domain of "broken link." So writing revocation out of the threat model seems like a practical decision. 3. Spoofing, however, seems unavoidable as an issue. It's trivially easy to construct a link which purports to be something else. All the YURL does is to prove that it is the real underlying link, without helping any in the spoofed presentation problem. That is, if I mail a million BoA account holders with my YURL and some standard text, it will work as well as if I didn't use a YURL, so adding the security aspect might create a false expectation, and nothing more! Is the YURL considered to be a generic replacement for links? If so, I don't see how it changes the big failure of secure browsing, which is the spoof attack. Mind you, I would, in the spirit of addressing the real security agenda, applaud any attempt to propose fixing up the current bad-and-getting-worse situation. It would seem that sharing and spreading the hash of server certs is definately a viable direction. -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
