At 02:42 PM 2/7/2002 -0500, Elliotte Rusty Harold wrote: >At 11:34 AM -0800 2/7/02, Asmus Freytag wrote: > >>But, as the discussion shows, spoofing on the word level (.com >>for .gov) is alive and well, and supported by any character set >>whatsoever. For that reason, it seems to promise little gain to >>try to chase the holy grail of a multilingual character set that >>somehow avoids the character level spoofing, if the word level >>spoofing can go on unchecked. > >Burglary at the broken window level is alive and well. Therefore there's >little point to putting locks on doors. > >I hope the fallacy of the above is obvious, but when translated into the >computer security domain it's all too common a rationalization, as this >thread demonstrates.
It is not obvious to me that there is a fallacy at all, let alone what it is. Instead of stating that we should be able to infer the fallacy, please state it, and a possible solution explicitly. It seems to me we have already proposed working, and available (if not elegant) solutions to the issue of trust of content. Now the issue seems to be trust of domain names. My browser already has built in support for identifying groups of domains I can assign varying levels of trust to, base on certificate technology. NOt elegant, but available. Similarly, something for email could e done using today's technology. More importantly, wrt DNS: under what circumstances can you, today, or in the future, actually trust that the address resolving information you get is accurate? None, really. The packets go too many places on the way that could change them. And even if it is accurate, which of course it usually is, how can you be sure that packets at a lower level will actually be delivered, as intended, and not misdirected or copied elsewhere? You can't, really, for the same reason. This is the nature of the system, especially at the IP level. None of this has to the slightest bit to do with what characters are used for domain names, and hence will not go away with any changes to DNS. It has everything to do with why data should be encrypted if you care about security of data. >There are many ways to socially engineer someone into doing something they >shouldn't do. This is just one of them, and one that's mostly theoretical >at the current time. However, we still need to plug the hole. >That there are other, less damaging holes (or even more damaging ones) is >no excuse for not fixing this one. The source code for bind is available. Go ahead and fix it. good luck persuading people to upgrade such a mission critical part of the internet though. >Just to pull a number out of a hat, imagine there are 10,000 attacks a day >using spoofing in the current system. Is this any justification for >opening up a hole that will add 10,000 more? Of course it's not. I still don't see the attack as anything but social engineering. That a telemarketer or door-to-door salesman can get my credit card info by misrepresenting their intent does not mean there is a flaw in either the phone numbering scheme, or the credit card system. Your attack is exactly analogous. Barry
