Firewall Wizards: Re: A fun smackdown...

[Chuck Swiger <chuck () codefab com>]

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