On 4/25/05, Gervase Markham <[EMAIL PROTECTED]> wrote: > Tyler Close wrote: > > On 4/21/05, Gervase Markham <[EMAIL PROTECTED]> wrote: > >>Petnames is not an authentication mechanism. It merely tells you that > >>the person you talked to last week is the person you are talking to now > > > > For the sake of clarity, could you define what you mean by "authentication". > > Good question. I mean being able to know who a person you are > communicating with is, in real life. In other words, if I phone my > mother, I authenticate her because I know her voice. If I email her, > even if I use her email address, she's not authenticated nearly as > strongly, as someone could be using her writing and typing style.
Ok, that explains our disagreement. This kind of "True Name" authentication is different from what I use the term "authentication" for. I use "authentication" for the part of a crypto protocol than ensures that the remote end posseses the private key corresponding to the public key used to initiate the connection. I describe the petname tool as an "authorization", or "accreditation" mechanism, since it provides the user with information about what actions are appropriate. For example, the petname tool tells the user that it is appropriate to treat the remote site as the same site you were using last week. > >>(and it doesn't even tell you that, if the cert is self-signed and your > >>DNS has been poisoned). > > > > This is incorrect. The petname tool does guard against DNS poisoning. > > The petname tool provides a reliable binding between an SSL identity > > and a user chosen reminder note. The petname tool does not rely on the > > correctness of DNS information. > > If the initial connection is made while DNS is poisoned, the petname > toolbar will be fooled. (I.e. the bound SSL identity is the incorrect one.) It won't be fooled, it will correctly record the SSL identity of the spoof site. When you later connect using DNS information that is not poisoned, the petname tool will correctly point out that you are talking to a different SSL identity. Given an https:// URL for a site using a self-signed certificate, I think this is the best that can be done by any mechanism. It is certainly much better than what Firefox currently provides. Are you suggesting otherwise? If I can introduce a new URL scheme, such as httpsy, I think I can improve upon this solution. Is it possible to add a new protocol to Firefox using an extension? > >>Sometimes this is sufficient - but not always, by any stretch of the > >>imagination. > > > > Note that I said: "For many use cases,..." I did not say "always". I > > think you'ld also be surprised at how often "knowing that you're > > talking to the same person" is sufficient. > > Oh, I agree that "knowing you are talking to the same person" is > sometimes sufficient. But you can't replace the trust model unless you > can cover all the bases. With the petname tool by itself, I am not trying to replace the trust model. I'm only trying to make the existing model work better, by protecting against phishing attacks. The more ambitious plan of replacing the trust model requires some more mechanism that I haven't implemented for Firefox yet. (snip) > > I'm just trying to make Firefox a better product. I'm offering a > > solution to a pressing problem facing Firefox, phishing and CA-list > > expansion, and providing the code to implement it. Surely this merits > > some consideration, if Firefox is serious about these issues. > > I personally don't agree that your solution is workable, and for a > change of that magnitude, I'm not the person you'd need to convince. Could you be more specific? Is the petname tool by itself a change of magnitude? Do you think the petname tool is not a workable anti-phishing mechanism? If so, could you explain why? Have you tried using it? Some skeptics have changed their minds about the petname tool after actually using it. Who do I need to convince that adding the petname tool to Firefox is a good idea? In what forum do I make my case? (snip) > > That's not the way security features are judged. Something that hasn't > > failed widely because it hasn't been widely attacked is not considered > > secure. > > You don't think any bad guys have considered how to subvert the current > system? I don't know a lot about the bad guys, but as a potential victim, it looks to me like the bad guys have not really tried to acquire SSL certificates under false credentials. It looks like they've found easier ways to subvert the current "secure" web browsing UI. The recent white papers indicate that once the bad guys do try to acquire SSL certificates with false credentials, they will have an easy time of it. We should be working ahead of the bad guys, not waiting to play catch-up. Tyler -- The web-calculus is the union of REST and capability-based security: http://www.waterken.com/dev/Web/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
