Re: MUSTs

[James Carlson <james.d.carlson@sun.com>]

ericb@digitaljunkyard.net writes:
>  "bs" == Bill Sommerfeld <sommerfeld@east.sun.com> writes:
> bs> Let's distinguish between what the tools check for, and actual
> bs> vulnerabilities, eh?
> 
> bs> This particular variance from the spec isn't a security problem, is it?
> 
> Sure it is.  It prevents authorized people from determining the
> configuration of the device by scanning.  Or something like that.

That sounds like it could be called a feature rather than a bug.  ;-}

> Bad code is rampant.  Heck, many of the devices we tested were
> terrible, awful, horrible, terrifying.  The idea behind this
> requirement was to ensure that at least a modicum of effort had been
> spent, that at least a minor clue had been involved in making sure
> that the device was functional as an Internet component.

I don't understand the point here.  I share your disgust with broken
devices, but I'm unclear on the problem being solved.  Why would we
assume that we could legislate good code?  Or that bad code
necessarily results in broken conformance to RFCs -- rather than just
exceedingly bad but conformant behavior?  Or that someone producing
bad code would label his box with a "Bad code inside!" sticker that
could be used to save any evaluator the effort of trying it?

If the applicable RFCs already say MUST/SHOULD/MAY in all the right
places, then what benefit is gained by having this document
*duplicate* those -- saying, in effect, "yes, you really had to do
that?"

And if the documents don't say MUST/SHOULD/MAY in all the right
places, what benefit is gained by declaring implementations that get
it right anyway (despite old spec errors) to be "non-conformant" with
this new document?

It seems to me that the underlying assumption here is that this
document becomes the single "pass this one special test and you're
Accepted as an Approved Internet Device" mechanism for multiple
markets.  Is this an achievable goal?

-- 
James Carlson, IP Systems Group                <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677