On Sat, 31 Jul 2004 09:10:24 EDT, Sal Mangiapane said:
> > Thank you. I was also looking for an RFC - if any -which documents why.
> >
> There is RFC3552 which is the Security Considerations Best Practices but
> it doesn't answer the WHY question.
At the risk of stating the obvious....
Anybody who actually reads rfc3552 all the way through, and still doesn't
understand *why* they should do a 'Security Considerations' analysis of their
new protocol, should be summarily judged as being too security-clueless to
write said section of their draft. (If anything, reading it should make you
wonder "Where's the woodpeckers, already?" (*))
And as a less obvious security-meta-consideration:
A protocol designed by (or with the assistance of) somebody security-clued is
probably in good shape, and no major surprises will likely be found while
writing up the Security Considerations (yes, there may be holes and weaknesses,
but you already *knew* that). A protocol designed by somebody not very
security-clued but at least security-aware may still be flawed, but hopefully
*some* thought has been put into the matter. A protocol designed by the
security-unaware is almost certain to have fatal flaws ("Authentication???
That's important?" ;)
(*) Woodpeckers - "If carpenters built buildings the way programmers write
software, the first woodpecker that came along would destroy civilization".
Fortunately, so far all the malware we've seen has been odd mutant woodpeckers
without well-formed beaks - it's only a few lines of code difference between
"Warhol Worm" and the cyberspace equivalent of Drexler's grey goo....
Attachment:
pgpf1ZB0VPado.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf