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 ====================================================================