Eric Rescorla wrote: > Huh? What are you claiming the problem with sending > client certificates in plaintext is (as if anyone uses > client certificates anyway)?
Well that is one problem - no one uses them, and no one should use them, while PKI was designed under the assumption that everyone would be using them. Another problem is that in practice the system merely ensures you are getting the purported domain name. Since we are overwhelmed by a multitude of irrelevant and confusing domain names, this is not much help. Further, I frequently get the warning that the certificate does not agree with the domain name when I know well that I am communicating with the intended entity - frequent misconfiguration results in false warnings, which I am thus trained to ignore, rendering the system entirely useless. Since we rely on passwords, social security numbers, and so forth, shared secrets, people are trained to give away secrets to purported authority, which creates the phishing hazard. We need to fix both problems. Of course, if the phishing hazard was fixed, we would still have the malware hazard, but we now know how to fix the malware hazard. We should fix both problems, rather than using one as an excuse for not fixing the other. We need to fix the network assuming the node is going to be made safe, and fix the node assuming the network is going to be made safe. >> Does anyone have an idea how we can fix this flaw >> within SSL/TLS within a reasonable timeframe, so that >> it can be implemented and shipped by the vendors in >> this century? Eric Rescorla wrote: > This gets discussed on the TLS mailing list > occasionally, but the arguments for making this change > aren't very convincing. If you have an actual credible > security argument you should post it to [EMAIL PROTECTED] I don't think that is a useful discussion forum. The IETF is moribund, paralyzed and increasingly irrelevant. If the internet is to be fixed, the fixes have to bypass the IETF. When one has a large group, group dynamics can make the large group a little bit smarter than its smartest members, but more commonly, make it a lot dumber than its dumbest members. If the IETF was capable of handling, or even noticing, the crisis that we in then we would not be in this crisis. To fix the phishing problem, we need to cryptographically secure relationships, rather than attempting to cryptographically secure true names, and to greatly reduce reliance on revealing shared secrets. It should be unusual and disturbing to reveal shared secrets, rather than routine, and it should only be done with humans, not machines. 1. As with Skype to Skype IM, the fact that you can receive a message from what purports to be an entity with which you have a relationship, should be compelling evidence that it really is that entity, the entity to which you have given a petname on your contacts list. Thus phishing is hard to initiate. As with Skype, what we seek to secure is petnames, not true names. We want to secure the bookmark list, and the list that comes up in a Google search. We want to secure that when you click on a the top entry of the Google list, you are contacting the intended entity. 2. As with Skype to Skype IM, this should be symmetric. If you respond to a message from your bank, or initiate a message to your bank, you should not have to reveal some shared secrets to prove an existing relationship before getting on with your task. Thus phishing should fail to catch any phish. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]