Re: A fun smackdown...

["Marcus J. Ranum" <mjr () ranum com>]

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.

> > 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? ;)

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 should
specify that all servers/services default their initial configuration to
untrusted mode. Do you have any idea how much grief that would
have saved us?

Are you defending the design philosophy of "make it work, fix it later"?

> 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!

> 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. Customers should *always* have
been specifying interoperation and security requirements in their
products. That never happened, so the vendors are running the
show. And, of COURSE they aren't going to "just do the right thing"
because it's not in their interest. That's why standards bodies
are *NEVER* effective in a market where there is still commercial
life. Standards only can happen once a market is commoditized
to the point where customers get their heads out of the sand and
realize "duh! my wireless stuff should work together"   -- I know
that's all counter-intuitive to you, if you're a believer in the standards
process, but think carefully about the success or non-success of
standards efforts depending on the stage a given technology is
at. There are some aberrations (like Wireless) where the vendors
recognize that they actually need to make things work together
*before* the market will blossom But as soon as it does, they
then try power-grabs.

Meanwhile, the standards bodies are increasingly left as weak
sisters that come up with standards that are literally years
too late to have meaningful impact - even if they were any good
(which they aren't)    Vis IPSEC. I had one of my engineers put
SwIPe into Gauntlet because IETF had been thinking "IP encryption
would be really nice" for 4 years and gotten noplace other than
debate. So we shipped product. Because there was $$ to be made.
And we told customers "We'll support IPSEC when and if it happens"
If we'd had customers that said "we won't buy your product until
it's compatible with Cisco" we'd have either done it or gone out of
business.

This industry is driven by market dynamics, not by standards
committees. Ignore the IETF (except to laugh at them) like
I do and focus on the economic incentives. The reason the
industry is screwed up right now is because the customers
have ceeded control to the vendors.

> Not always.  There are people, even on this list, who could learn something from:
>
> http://www.ietf.org/rfc/rfc2196.txt

That 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.

>   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 on
the 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.

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."

mjr. 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards