From: Hal Lockhart <Harold.Lockhart@platinum.com>
Date: Thu, 29 Oct 1998 05:18:58 +0800
To: Steve Bellovin <smb@research.att.com>
Subject: Re: log files (was: Re: dbts: Cryptographic Dog Stocks, The Dirigible Biplane, and Sending the Wizards Back to Menlo Park )
In-Reply-To: <199810281713.MAA29423@postal.research.att.com>
Message-ID: <3.0.1.32.19981028153554.00a4cc3c@pop.bos.platinum.com>
MIME-Version: 1.0
Content-Type: text/plain



Steve,

I think in general we are in violent agreement, as are most real world
practitioners I have spoken to.  I won't even argue about whether your
original comment constituted "resisting a strong measure in favor of a weak
measure".  Let's just say that your comment brought to mind certain unnamed
persons who have done this.

However, I believe you missed my points in several other areas, so I will
try to clarify what I was saying.  Out of courtesy to the numerous lists we
are cross posting to, after your next response, if any, I suggest we take
this off list.

At 12:13 PM 10/28/98 -0500, Steve Bellovin wrote:
>In message <3.0.1.32.19981028093825.00a3f2d0@pop.bos.platinum.com>, Hal
Lockhar
>> 
>> I hear you saying, "but what if the guy is trying to break into my system."
>>  I would argue, that if you are using strong cryptographic authentication
>> (whether his identity can be mapped to a human being or not) then either 1)
>> he will fail, in which case you don't care or 2) he will succeed, in which
>> case he must have used some technique like stealing a key which cannot be
>> detected by monitoring.
>
>Why do you assume that the flaw that lets the bad guy in is cryptographic?
>I recently analyzed every CERT advisory ever issued.  85% of them
>described problems that crypto couldn't fix.  Buffer overflow is the
>culprit du jour, but it's hardly the only one.  (This year, the prize
>for second place -- admittedly a distant second -- went to crypto modules.)

I never said that the flaw was cryptographic.  The idea I was trying to
express was that are two cases:

1) (Today) Let in unauthenticated or weakly authenticated users.  There is
a (relatively) high probability that they are attackers who will try to
exploit some weakness like a buffer overflow. In this case it is useful to
observe their application level traffic in order to detect this or learn of
the existence of the new crack they are using.

2) (Future) Allow only strongly authenticated users.  Either a) they are
legitimate users whose identity is known and will presumably not try to
hack the system, or b) they are attackers who have done something like
steal the key of a legitimate user.  In the later case, I admit you might
want to see what they are typing, but it will not give you any information
about the underlying problem -- their ability to obtain unauthorized keys.

>> I raise this point, because I see it as part of a current trend to resist
>> stong security measures in preference to weak ones.  The current industry
>> facination with weak measures, like firewalls and intrusion detection
>> systems has caused some people to resist the introduction of strong
>> measures, such as cryptographic authentication and data protection.  The
>> most popular example of this is the foolish practice of putting an SSL
>> server, with its vital server private key, outside the firewall in a DMZ.  
>
>That's only a flaw if you assume that there are other weak points on
>the Web server that a firewall can protect.  If you lock down the host
>so that only port 80 is exposed (and maybe a cryptographically protected
>administrative port), what good does the firewall do?  The weakest point
>is probably the CGI scripts, and those have to be exposed in any event.

I agree with that. It is amazing to me how many people enable crypto like a
talisman without locking down the rest of the system.  

However, my point was that as I understand the theory behind a DMZ, you put
systems there that you think might get overrun.  You do not put the
mainframe that runs payroll in the DMZ. Yet, I assert, the server private
key, which represents the identity of the organization ought to fall in
under the same classification and receive the same protection. (Its
actually worse than I indicated, since if you want your server to restart
without human intervention, you generally have to put the pass phrase in a
script file or something.
 
>> But I have also heard system administrators protest the introduction of
>> cryptographic solutions because some current half measure will no longer
>> work.  There are even misguided individuals who have proposed putting
>> master decryption keys at vulnerable locations like border routers, so that
>> messages can be inspected in the fly.
>
>There are no panaceas, there is no single technology (and that emphatically
>includes crypto) that will solve this problem.  Defense in depth is our
>best hope, which means firewalls plus crypto plus IDS plus better operating
>systems and programming languages.  Most of all, it means engineering a
>solution -- making the right set of tradeoffs, even if unobvious.

Agreed.  I have no problem with defense in depth.  Only, as I said,
limiting the use of a strong technique because it interferes with the use
of a weak one.

>Let me give an analogy.  On most electrical equipment, the ground pin
>is useless -- *unless* there has been another insulation or air gap
>failure within the device, a failure that would render the frame "hot".
>But because of the ground pin, such a failure will instead short the
>hot lead to ground, tripping the breaker.  It thus takes two failures
>to electrocute someone.  *But* -- toasters and other devices with
>exposed heating elements don't use this technique.  Why not?  Well,
>with an exposed electrode, the probability of direct contact with a live
>wire is much greater.  And if you ground the frame of the toaster,
>there's now a direct, high-quality path to ground that in turn is
>in contact with the other hand of the poor fool who is poking at a
>piece of bread with a fork.  In other words, what's a safety mechanism
>in your refrigerator is a danger in your toaster -- and sometimes,
>that can be true of crypto as well.

I guess I don't see the case where the use of crypto decreases security,
except if a mis-design causes complacency.  In my mind, strong security
begins with strong (cryptographic) authentication. [Calm down Bob, I am not
ruling out non-biologic identities.]  If we have authentication, we can
have access control, audit trails, etc.  We can certainly add heuristic
measures like firewalls and IDS and potentially detect additional problems.
 However, I have met more that a few people who want to play with an IDS
because it is cool, rather than go through the hard and unsexy work of
locking down their systems.

>For another analogy, think of insecurity as entropy.  You can't destroy
>it, but you can move it around.  

Do you have any evidence for this remarkable assertion?  It sounds like a
council of despair to me.  Are you saying that no matter what we do or how
much we spend, we can not make systems more secure.  Say it ain't so!

>Using crypto moves the problem from
>the (in)security of the links to the (in)security of the keys.  If
>you can't protect your keys -- and that generally takes much more than
>crypto -- using cryptography hasn't bought you anything.

I agree that as we raise the bar, new attacks become the weakest link, but
that does not mean you have not increased security. The new weakest links
are no weaker in an absolute sense. 

A better analogy is computer performance improvement.  If we speed up the
current bottleneck, something else becomes the bottleneck, but that doesn't
mean the system won't run faster.

The practical reality of the Internet today is best illustrated by the
story of the hikers and the mountain lion.  When the hikers encounter a
mountain lion one begins to tie on his running shoes.  The other says "you
can't outrun him with or without running shoes."  The first answers "I
don't have to outrun him, just you."

The serious hackers don't waste their time trying to break into AT&T, they
pick some place easier. (like the CIA ;-)

Regards,

Hal

====================================================================
Harold W. Lockhart Jr.               PLATINUM technology
Chief Technical Architect            8 New England Executive Park
Email: Harold.Lockhart@platinum.com  Burlington, MA 01803 USA
Voice: (781)273-6406                 Fax: (781)229-2969
====================================================================