Re: IIS to as/400 odbc

From: Joe Pluta <joepluta@PlutaBrothers.com>

> How does this apply to the conversation?  More importantly, how does it
> help?  It's a nice quote, but not particularly helpful.
>
> Are you saying proprietary protocols are NOT more secure than published
> protocols?  Or are you saying that there is a protocol that matches the
> analogy Mr. Schneier uses?  If so, what is it, and how easy is it to
> implement?  Rather than tell me what you DON'T like about my approach, tell
> me what yours is.
>
> Criticism without alternative, especially second-hand criticism, is
> intellectually lazy, and I expect better from you, Leif.
>
> Joe
>

Being intellectually lazy, I'll answer first with yet another second-hand
quote (at least I'm into re-use here):

Since it is difficult to design good security, and since this is very
expensive, a lot of work has been done recently to try to standardize
security. Even as I speak the International Standards Organization
is meeting to decide on this very issue. Since there is a lot of confusion
on this point I have been asked to make the position clear. The
purpose of language is to convey information.  This only works if
 both sender and receiver of information both use the same system.
In other words, language only works precisely because it is standardized.

The purpose of cryptography on the other hand is to make the message
unintelligible except to one person.  In other words cryptography only
works precisely because it is NOT standardized.

So what they do is to make most of the cipher standardized, and
to concentrate the non-standardization into one part called the key.

So far so good. But of course the key, the non-standardized part,
must be nonstandard in only standardized ways. And also key
management must conform to certain standards. In other words
standards are being formulated whereby the nonstandard parts,
which must conform to certain standards of non-standardization
are also to be handled only in a standardized nonstandard way
in order to standardize on the overall non-standardization.

John Gordon http://www.conceptlabs.co.uk/alicebob.html


======> but, (and this is me now, not second-hand or anything
less than what one might expect of me) I think that a well-designed
and well-documented proprietary protocol is good because it
lets you retain control over your application, not because it
is used as a substitute for active security measures. One can
combine the proprietary protocol with strong security: use
of e.g. AES, use of good sources of entropy, etc. Such use,
of course, depending on the specific requirement for security.
Using an AS/400 is already a step in the right direction all in
itself. Now, you can easily nullify that advantage by having
e.g. a 3-tier application: Windoze <-> Micro$oft server <-> As/400
unless you build in your own security.


>
> > From: Joe Pluta <joepluta@PlutaBrothers.com>
> >
> > > As the script kiddies get more sophisticated, Leif, I think you
> > need both
> > > strong network policy procedures and proprietary protocols
> >
> > To quote Bruce Schneier (Preface to Applied Cryptography):
> >
> > "If I take a letter, lock it in a safe, hide the safe somewhere
> > in New York,
> > then tell you to read the letter, that's not security. That's obscurity.
> > On the other hand, if I take a letter and lock it in a safe, and then
> > give you the safe along with the design specifications of the safe
> > and a hundred identical safes with their combinations so that you
> > and the world's best safecrackers can study the locking mechanism
> > - and you still can't open the safe and read the letter - that's
> > security."
> >
> > Just make sure that having a proprietary protocol (which has other
> > problems such as finding people to maintain it after you are gone)
> > does not become a convenient "pillow of complacency".
>