Bernstein on Convex
Mark Crispin
my personal workstation without a non-Convex host appearing in the header
someplace.
He is wrong. It is possible. It would take a bit of effort to set up the
attack properly, as well as some experimentation to gain some useful
information about the internals of the Convex network, but it can be done.
I will not go into the details of the attack, other than to say that there is
a difference between what you *think* is part of your infrastructure and what
has been made part of your infrastructure. There are things you can do with
certain IP protocols that may surprise you.
Again, these are techniques beyond your typical clueless freshman, but they
are also well-suited to being written up, step-by-step fashion, in cracker
publications.
RFC-931 is worse that security by obscurity. It is security by complexity.
There is nothing obscure about RFC-931; no secret that if well-guarded would
stop a bad guy.
If you think that RFC-931 solves any problems, you probably also think that
shadow password files eliminate the need for making people pick passwords that
won't succumb to a password cracker.
Bernstein may have some good ideas, but he is treading into the area of
quackery. A quack may be sincere -- that is what distinguishes the quack from
the fraud -- but is even more dangerous because of it. I suggest that
Bernstein reassess what he is trying to push on people. If he spent half the
amount of effort working on PEM that he did denouncing it, we might well have
had a PEM infrastructure in place by now.
Dan Bernstein
that TCP is hardly a secure protocol---is valid, although it was already
covered by my category (5). From there your commentary has gone steadily
downhill. Now you're so desperate to defend your position that you want
alt.security readers to believe that you can get through paranoid
Internet gateways. Yeah, right. Of course, as always, you aren't
justifying anything you say. Cut your reputation's losses: stop now.
(To answer the flood of requests: Steve Bellovin's paper on TCP/IP
security is currently available from inet.att.com via anonymous ftp as
dist/ipext.ps.Z. There's lots of other goodies in that directory,
including Bill Cheswick's paper on building a secure Internet gateway.
I'm afraid I don't have Steve's permission to distribute his DNS paper,
though I can't imagine why he wants to keep it restricted---what is
this, security by obscurity? Ask s...@inet.att.com if you need a copy.)
Back to you, Mark. You say that authd is ``security by complexity.''
Don't be ridiculous. I was talking with Phill Gross, IETF Chairman, the
other day, and he was pleasantly surprised to see that the current authd
protocol spec was *four pages long*. Does there exist a simpler security
protocol? (Do you also spew idiotic diatribes against DECNet, which
since its inception has included in its transport protocols exactly the
same functionality that authd would add to TCP?)
You try to discount the claim that RFC 931 solves any problems. Again
you're displaying this puerile ``I know better than you do, and I'm
going to make your decisions for you!'' attitude. It seems to me that
the common problem of users hiding behind SMTP and a big multiuser
machine is, indeed, a problem, and it's obvious to anyone with a brain
that RFC 931 does solve that problem. Maybe you don't have this problem,
Mark; fine. Other people do. For them RFC 931 solves problems.
You claim that I have ``denounced'' PEM. Don't be ridiculous. I have
done nothing more than observed PEM's current status: namely, vaporware.
Vaporware isn't useful, Mark. It doesn't run.
Finally, Mark, you imply that if I directed the energy I've spent on
talking about vaporPEM into working on it, ``we might well have had a
PEM infrastructure in place by now.'' Really? In fifteen minutes I could
do all that? I didn't realize vaporPEM was being handled by such idiots!
If I had stepped in I could have ended these years of waiting---in
fifteen minutes? Incredible! Are you sure this is what you wanted to
say, Mark?
---Dan