Firewall Wizards mailing list archives
Re: A fun smackdown...
From: Chuck Swiger <chuck () codefab com>
Date: Sat, 21 May 2005 14:02:49 -0400
On May 21, 2005, at 12:31 PM, Marcus J. Ranum wrote:
Chuck Swiger wrote:I'd rather see an explicit statement that says, "this is not a secure protocol", then use something which pretends to be secure, yet is not.Um, no. If it's going to be standardized for widespread deployment on the Internet it needs to address security. Period. The days are over when people can just ignore that; that's part of how we got into the mess we're in now.
I would agree that every protocol needs to address security, in the broader sense of the word, which includes "how should legitimate access work?" and "how can we ensure service availability?" and "what should we do about malicious users?" If you mean "security" only in the sense that every protocol needs to "deny access", I would disagree.
Let's consider the problem of securely accessing resources like source tarballs. If I "cd /usr/ports", and do a "make fetch", my machine will try to get ~12000 source tarballs via my HTTP proxy. Is there a risk here, of malicious code lurking in a tarball which has been tampered with? Of course. The ports system [1] addresses this by publishing checksums (MD5, SHA, PGP/GPG-signed) via many channels.
If you get a DL with a bad checksum, the system will try to fetch a valid one from other mirror sites, or it will stop. The user can then manually obtain a valid one, or do a build using the tarball which failed the checksum if they trust the change to be benign. (The common case is that you are the one who changed it, and you'll publish a new checksum to others as you update that particular port to a new version of the software.)
The RFC process creates interoperable *CRAP*.Let's accept this as true for a moment. Can you point to something better?Oh, I see. Because I'm pointing out that something's broken, it's my job to fix it? ;)
In my experience, problems are a lot more likely to be solved by the people who notice and decide to care about whatever the issue is, then by people who do neither.
This being said, I didn't ask you to *fix* anything, per se.I simply asked whether you knew of something better, not whether you'd written something better.
(But I'm not concerned about you being too bashful.... :-)
Actually, my previous Email contained a perfectly decent suggestion, namely that standards should specify separate operational stacks depending on use to which the protocols are being put. That requires some forethought in the design process, of course. Lack of which is the entire problem. Standards should at a minimum specify trusted mode operation distinctly from untrusted mode operation, and shouldspecify that all servers/services default their initial configuration tountrusted mode. Do you have any idea how much grief that would have saved us?
Sure. An optimist would say that the nice thing about the past is that it cannot be changed.
Security professionals aren't paid to be optimists....
Are you defending the design philosophy of "make it work, fix it later"?
Nope. If you need to fix it later, you didn't do a good job of making it work in the first place.
What about the ISO model, the X.400 & X.500 schemas, and ASN.1?How well has BER, SNMP, SSL certs, and all of that done in practice for security?I didn't say ISO was any good, either! <LOL> C'mon... I've been bashing standards committees as useless on this mailing list since the first day I started it!
If you want to call every standard useless, you're welcome to that opinion. Even so, it might be useful to figure out if some standards are less useless than others...
Or how about the security vendors, who break standards to create proprietary, non-interoperable crap?Stupid customers who give thier money to vendors that do that, deserve what they get. Stupid customers who buy "mission critical" products that don't interoperate with other "mission critical" products, deserve what they get. Stupid customers who buy cool widgets with blinky lights that do "deep inspection" deserve what they get. Let's look at the problem from a completely different perspective for a second. Do you CARE if there is a standard, if everything works together? I.e.: who cares if it's written down. Make it the vendors' problem to make sure it works.
Maybe that perspective would work for someone who is only a consumer of end-user products, but anyone who builds their own systems or writes their own software ought to care whether they are implementing something which meets relevant standards, baselines, government rules, etc.
Sure I care. Not all standards are relevant. Not all parts of a particular standard are relevant, or should be permitted or enabled by default. But standards matter some, depending on the situation and the security requirements....
Not always. There are people, even on this list, who could learn something from:http://www.ietf.org/rfc/rfc2196.txtThat document summarizes a set of observations of how real-world stuff behaves in practice. That's not a "standard" that's a "security for dummies" guide. If it was a standard, it would say "do NOT build your own firewall" etc.
I can't say that I've ever owned a "XXX for dummies" guide, as the mindset doesn't exactly appeal, but I don't see much benefit to abusing people who are trying to learn, either. I suppose that lots of people act poorly when they feel especially competitive.
As an aside, building a "home grown" firewall requires a significant amount of skill and knowledge of TCP/IP. It should not be trivially attempted because a perceived sense of security is worse in the long run than knowing that there is no security. As with all security measures, it is important to decide on the threat, the value of the assets to be protected, and the costs to implement security.Give that RFC a fair read, Marcus, and then see whether you still agree with your own generalization above.Like I said, it's a how-to guide. It was written prior to 1997, based onthe experiences of people who had been out "being there and doing that" since the late 1980's. I see some of my old TIS co-workers helped author that RFC. Co-workers who were sitting in their offices doing "theoretical computer security" while I was out installing firewalls all over the place.
Every one else's experiences were theoretical? When you get done preaching, you can always try out for Brian's role in that Monty Python sketch....
Always look on the brighter side, Marcus. :-)
In other words, RFC 2196 documents acquired common sense. Useful standards (if there were such a thing) would provide roadmaps to the future, not "here's what we learned in the past."
Useful criticism often includes suggestions for improvement. -- -Chuck _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Re: A fun smackdown..., (continued)
- Re: A fun smackdown... Marcus J. Ranum (May 21)
- Re: A fun smackdown... Don Kendrick (May 24)
- Re: A fun smackdown... Paul D. Robertson (May 19)
- Re: A fun smackdown... Chuck Swiger (May 19)
- Re: A fun smackdown... Paul D. Robertson (May 19)
- Re: A fun smackdown... Chuck Swiger (May 19)
- Re: A fun smackdown... Paul D. Robertson (May 19)
- Re: A fun smackdown... Marcus J. Ranum (May 20)
- Re: A fun smackdown... Chuck Swiger (May 21)
- Re: A fun smackdown... Marcus J. Ranum (May 21)
- Re: A fun smackdown... Chuck Swiger (May 21)
- Re: A fun smackdown... Marcus J. Ranum (May 21)
- RE: A fun smackdown... Bill Royds (May 24)
- Re: A fun smackdown... Joseph S D Yao (May 20)
- Re: A fun smackdown... Chuck Swiger (May 20)
- Re: A fun smackdown... Joseph S D Yao (May 20)
- Re: A fun smackdown... Devdas Bhagat (May 20)
- Re: A fun smackdown... Carson Gaspar (May 20)
- Re: A fun smackdown... Marcus J. Ranum (May 20)
- RE: A fun smackdown... lordchariot (May 21)
- Re: A fun smackdown... Devdas Bhagat (May 19)