CRYPTO-GRAM

                March 15, 2000

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            schneier@counterpane.com
           http://www.counterpane.com


A free monthly newsletter providing summaries, analyses, insights, and 
commentaries on computer security and cryptography.

Back issues are available at http://www.counterpane.com.  To subscribe or 
unsubscribe, see below.


Copyright (c) 2000 by Counterpane Internet Security, Inc.


** *** ***** ******* *********** *************

In this issue:
      Kerberos and Windows 2000
      Counterpane -- Featured Research
      News
      AES News
      Counterpane Internet Security News
      Software as a Burglary Tool
      The Doghouse:  The Virginia Legislature
      Software Complexity and Security
      Comments from Readers


** *** ***** ******* *********** *************

          Kerberos and Windows 2000



Kerberos is a symmetric-key authentication scheme.  It was developed at MIT 
as part of their Project Athena in the 1980s -- the protocol was published 
in October 1988 -- and has been implemented on various flavors of 
UNIX.  The current version is Kerberos Version 5, which corrected some 
security vulnerabilities in Version 4.  It's never taken over the 
authentication world, but it is used in many networks.  These days, the 
Internet Engineering Task Force (IETF) controls the specification for Kerberos.

Kerberos is a client-server authentication protocol.  (_Applied 
Cryptography_ goes into the protocol in detail.)  For the point of this 
article, remember that there is a secure Kerberos server on a 
network.  Clients log into the Kerberos server and get secure 
"tickets."  The clients can use these tickets to log onto other servers on 
the network: file servers, databases, etc.

Kerberos is now part of Microsoft Windows 2000, sort of.  The issue is that 
Microsoft has made changes to the protocol to make it noninteroperable with 
the Kerberos standard, and with any products that implement Kerberos correctly.

Specifically, the incompatibility has to do with something called the "data 
authorization field" in the Kerberos messages.  All major Kerberos 
implementations leave the field blank.  The new Microsoft implementation 
does not; it uses the field to exchange access privileges between the 
Kerberos server and the client.

There are two ways to look at this:

o   Since the field has no specific uses in the protocol (and no one else 
uses it), the fact that Microsoft is using the protocol is harmless.

o   Because Microsoft is refusing to publish details about its proprietary 
use of the field, they are harming interoperability and 
standardization.  Other Kerberos vendors cannot directly support Windows 
2000 clients.

Even worse, Microsoft bypassed the IETF in this process (there's a 
procedure you're supposed follow if you want to enhance, deviate from, or 
modify an IETF standard).

On the surface, this is just nasty business practices.  If you're a company 
that has invested in a UNIX-based Kerberos authentication system and you 
want to support Windows 2000 desktops, your only real option is to buy a 
Windows 2000 Kerberos server and pay for the integration.  I'm sure this is 
what Microsoft wants.

My worry is more about the security.  Protocols are very fragile; we've 
learned that time and time again.  You can't just make changes to a 
security protocol and assume the changed protocol will be 
secure.  Microsoft has taken the Kerberos protocol -- a published protocol 
that has gone through over a decade of peer review -- and has made changes 
in it that affect security.  Even worse, they have made those changes in 
secret and have not released the details to the world.

Don't be fooled.  The Kerberos in Windows 2000 is not Kerberos.  It does 
not conform to the Kerberos standard.  It is Kerberos-like, but we don't 
know how secure it is.

Kerberos Web page:
<http://www.isi.edu/gost/gost-group/products/kerberos/>

IETF Specification:
<ftp://ftp.isi.edu/in-notes/rfc1510.txt>
<ftp://athena-dist.mit.edu/pub/kerberos/doc/techplan.txt>

Microsoft Kerberos information:
Windows 2000 Kerberos Authentication white paper --
<http://www.microsoft.com/windows2000/library/howitworks/security/kerberos.asp>
Introduction to Windows 2000 Security Services --
<http://www.microsoft.com/WINDOWS2000/guide/server/features/secintro.asp>
Guide to Kerberos Interoperability --
<http://www.microsoft.com/windows2000/library/planning/security/kerbsteps.asp>
Article by David Chappell about Kerberos and Windows 2000 --
<http://www.microsoft.com/msj/defaulttop.asp?page=/msj/0899/kerberos/kerbero 
stop.htm>


** *** ***** ******* *********** *************

       Counterpane -- Featured Research



"A Performance Comparison of the Five AES Finalists"

B. Schneier and D. Whiting, Third AES Candidate Conference, 2000, to appear.

In 1997, NIST announced a program to develop and choose an Advanced 
Encryption Standard (AES) to replace the aging Data Encryption Standard 
(DES).  NIST chose five finalists in 1999.  We compare the performance of 
the five AES finalists on a variety of common software platforms: current 
32-bit CPUs (both large microprocessors and smaller, smart card and 
embedded microprocessors) and high-end 64-bit CPUs.  Our intent is to show 
roughly how the algorithms' speeds compare across a variety of CPUs.  Then, 
we give the maximum rounds cryptanalyzed for each of the algorithms, and 
re-examine all the performance numbers for these variants. We then compare 
the algorithms again, using the minimal secure variants as a way to more 
fairly align the security of the five algorithms.

<http://www.counterpane.com/aes-comparison.html>


** *** ***** ******* *********** *************

                     News



More commentary on the ethics of publicizing vulnerabilities:
<http://boardwatch.internet.com/mag/99/oct/bwm62.html>
<http://cgi.zdnet.com/slink?22157:8469234>

An opinion on DDS attacks and the CD Universe fiasco:
<http://www.osopinion.com/Opinions/GaryMurphy/GaryMurphy7.html>

There's a new DSS standard:
Text --
<http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=2000_register&doc 
id=00-3450-filed>
PDF --
<http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=2000_register&doc 
id=00-3450-filed.pdf>

BAIT, DIRT, and other law-enforcement hacker tools.  Some of the PR fluff 
sounds too good to be true.
<http://www.codexdatasystems.com/>

H&R Block insecurity:
<http://news.cnet.com/news/0-1005-200-1550948.html?tag=st.ne.1002.tgif?st.ne 
fd.gif.d>

The worst security product is the one that isn't used.  Here are the 
results of a PGP usability study.  Most people can't figure out how to use 
it.  Some sent e-mail out unencrypted, believing it was secure.
<http://www.wired.com/news/news/business/story/21484.html>
<http://www.cs.cmu.edu/~alma/johnny.pdf>

Novell published a "security flaw in MS Active Directory Services" the day 
before the MS launch of Windows 2000.  Microsoft published a response 
shortly thereafter.  Both documents are full of marketing spin.  Russ 
Cooper has written an objective description of the non-issue:
<http://ntbugtraq.ntadvice.com/NDSvsADS-01.asp>

Good security software:  a command-line tool for statically scanning C and
C++ source code for security vulnerabilities.  It's called ITS4.
<http://www.rstcorp.com/its4/>

Mixter's paper on cracking:
<http://mixter.void.ru/crack.txt>

Excellent essay on the difference between hackers and vandals:
<http://www.villagevoice.com/issues/0007/thieme.shtml>

Commentaries on distributed denial-of-service attacks:
<http://www.pbs.org/cringely/pulpit/pulpit20000217.html>
<http://www.thenation.com/issue/000313/0313klein.shtml>

Usernames and passwords for sale:
<http://www.wired.com/news/politics/0,1283,34515,00.html?tw=wn20000224>

Sony PlayStation 2 is being held up for export (from Japan) due to crypto 
in the system:
<http://www.theregister.co.uk/000302-000026.html>

Navajo code-talking GI Joe doll:
<http://www.gijoe.com/lnavajo_code_talker.html>

More speculation about Echelon:
<http://www.zdnet.com/enterprise/stories/security/news/0,7922,2455560,00.html>
<http://www.wired.com/news/politics/0,1283,34932,00.html>

Interesting use of a honey pot by the San Diego Supercomputer Center (or, 
SDSC Hacks the Hackers):
<http://security.sdsc.edu/incidents/worm.2000.01.18.shtml>


** *** ***** ******* *********** *************

                    AES News



The big AES news is the week of 10-14 April, 2000, in New York.  Monday, 
Tuesday, and Wednesday are the 7th Fast Software Encryption workshop (FSE 
2000).  Thursday and Friday are the 3rd AES Candidate Conference 
(AES3).  Both are in the New York Hilton and Towers.  FSE 2000 will have 
several excellent papers on the AES candidates (new attacks on MARS, RC6, 
Rijndael, and Serpent), and AES3 will have nothing but.  The papers for FSE 
2000 have been selected, and are listed on the Web site.  The papers for 
AES3 have not been announced yet.  (The submission deadline for both 
conferences is long past.)

Come, be a part of cryptography history.  It'll be fun.

FSE 2000:
<http://www.counterpane.com/fse.html>

AES3:
<http://csrc.nist.gov/encryption/aes/round2/conf3/aes3conf.htm>


** *** ***** ******* *********** *************

      Counterpane Internet Security News



Bruce Schneier was interviewed in Business Week:
<http://www.businessweek.com/2000/00_10/b3671089.htm>


** *** ***** ******* *********** *************


          Software as a Burglary Tool



This is a weird one.  Two people in Minneapolis who allegedly stole 
information from their employers were charged with the possession of a 
"burglary tool" -- L0phtcrack, the program that automatically breaks 
Windows passwords.

The ramifications of this are unclear.  There are some burglary tools that 
you can't carry unless you are a licensed professional (certain lockpicking 
tooks, for example); just having them is illegal.  But screwdrivers and 
bolt cutters can also be burglary tools if they are used with the intent to 
commit a crime.

What it means to me is that the law is getting serious about this.

<http://www.channel4000.com/news/stories/news-20000217-164727.html?&_ref=100 
  5006010>


** *** ***** ******* *********** *************

    The Doghouse:  The Virginia Legislature



They recently passed the Uniform Computer Information Transactions Act 
(UCITA).  It's deeply disturbing.  It could be subtitled "The Software 
Industry Wish List" for the amount of control (and absence of 
accountability) it gives UNDER LAW to software distributors.

Under the UCITA, Microsoft not only doesn't have to fix any of the 63,000 
Windows 2000 bugs, it wouldn't even have to tell you any of them 
existed.  It could also disable the OS of anyone it wants for essentially 
any reason it wanted (e.g., failing to abide by the license terms which 
restrict you from any public mention of apparent bugs in the software).

The governor has not signed the bill into law yet, but he is expected to.

<http://www.lawnewsnetwork.com/practice/techlaw/news/A16380-2000Feb16.html>
<http://www4.zdnet.com:80/intweek/stories/news/0,4164,2436874,00.html>
<http://www.computerworld.com/home/print.nsf/CWFlash/000215ECDA>
<http://www.cnn.com/2000/TECH/computing/03/07/ucita.idg/index.html>


** *** ***** ******* *********** *************

        Software Complexity and Security



The future of digital systems is complexity, and complexity is the worst 
enemy of security.

Digital technology has been an unending series of innovations, unintended 
consequences, and surprises, and there's no reason to believe that will 
stop anytime soon.  But there is one thing that has held constant through 
it all, and it's that digital systems have gotten more complicated.

We've seen it over the past several years.  Microprocessors have gotten 
more complex.  Operating systems have gotten more complex.  Computers have 
gotten more complex.  Networks have gotten more complex.  Individual 
networks have combined, further increasing the complexity.  I've said it 
before, but it's worth repeating:  The Internet is probably the most 
complex machine mankind has ever built.  And it's not getting any simpler 
anytime soon.

As a consumer, I think this complexity is great.  There are more choices, 
more options, more things I can do.  As a security professional, I think 
it's terrifying.  Complexity is the worst enemy of security.  This has been 
true since the beginning of computers, and is likely to be true for the 
foreseeable future.  And as cyberspace continues to get more complex, it 
will continue to get less secure.  There are several reasons why this is true.

The first reason is the number of security bugs.  All software contains 
bugs.  And as the complexity of the software goes up, the number of bugs 
goes up.  And a percentage of these bugs will affect security.

The second reason is the modularity of complex systems.  Complex systems 
are necessarily modular; there's no other way to handle the complexity than 
by breaking it up into manageable pieces.  We could never have made the 
Internet as complex and interesting as it is today without modularity.  But 
increased modularity means increased security flaws, because security often 
fails where two modules interact.

We've already seen examples of this as everything becomes 
Internet-aware.  For years we knew that Internet applications like sendmail 
and rlogin had to be secure, but the recent epidemic of macro viruses shows 
that Microsoft Word and Excel need to be secure.  Java applets not only 
need to be secure for the uses they are intended, they also need to be 
secure for any other use an attacker might think of.  Photocopiers, 
maintenance ports on routers, mass storage units: these can all be made 
Internet-aware, with the associated security risks.  Rogue printer drivers 
can compromise Windows NT.  Malicious e-mail attachments can tunnel through 
firewalls.  Convenience features in Microsoft Outlook can compromise security.

The third reason is the increased testing requirements for complex 
systems.  I've talked elsewhere about security and failure testing.  The 
only reasonable way to test the security of a system is to perform security 
evaluations on it.  However, the more complex the system is, the harder a 
security evaluation becomes.  A more complex system will have more 
security-related errors in the specification, design, and 
implementation.  And unfortunately, the number of errors and the difficulty 
of evaluation does not grow in step with the complexity, but in fact grows 
much faster.

For the sake of simplicity, let's assume the system has ten different 
settings, each with two possible choices.  Then there are 45 different 
pairs of choices that could interact in unexpected ways, and 1024 different 
configurations altogether.  Each possible interaction can lead to a 
security weakness, and must be explicitly tested.  Now, assume that the 
system has twenty different settings.  This means 190 different pairs of 
choices, and about a million different configurations.  Thirty different 
settings means 435 different pairs and a billion different 
configurations.  Even slight increases in the complexity of systems mean an 
explosion in the number of different configurations . . . any one of which 
could hide a security weakness.

The increased number of possible interactions creates more work during the 
security evaluation.  For a system with a moderate number of options, 
checking all the two-option interactions becomes a huge amount of 
work.  Checking every possible configuration is effectively 
impossible.  Thus the difficulty of performing security evaluations also 
grows very rapidly with increasing complexity.  The combination of 
additional (potential) weaknesses and a more difficult security analysis 
unavoidably results in insecure systems.

The fourth reason is that the more complex a system is, the harder it is to 
understand.  There are all sorts of vulnerability points -- human-computer 
interface, system interactions -- that become much larger when you can't 
keep the entire system in your head.

The fifth (and final) reason is the difficulty of analysis.  The more 
complex a system is, the harder it is to do this kind of 
analysis.  Everything is more complicated: the specification, the design, 
the implementation, the use.  And as we've seen again and again, everything 
is relevant to security analysis.

A more complex system loses on all fronts.  It contains more weaknesses to 
start with, its modularity exacerbates those weaknesses, it's harder to 
test, it's harder to understand, and it's harder to analyze.

It gets worse:  This increase in the number of security weaknesses 
interacts destructively with the weakest-link property of security: the 
security of the overall system is limited by the security of its weakest 
link.  Any single weakness can destroy the security of the entire system.

Real systems show no signs of becoming less complex.  In fact, they are 
becoming more complex faster and faster.  Microsoft Windows is a poster 
child for this trend to complexity.  Windows 3.1, released in 1992, had 3 
million lines of code; Windows 95 has 15 million and Windows 98 has 18 
million.  The original Windows NT (also 1992) had 4 million lines of code; 
NT 4.0 (1996) has 16.5 million.  In 1998, Windows NT 5.0 was estimated to 
have 20 million lines of code; by the time it was renamed Windows 2000 (in 
1999) it had between 35 million and 60 million lines of code, depending on 
who you believe.  (As points of comparison, Solaris has held pretty stable 
at about 7 to 8 million lines of code for the last few releases, and Linux, 
even with the addition of X Windows and Apache, is still under 5 million 
lines of code.)

The size of Windows 2000 is absolutely amazing, and it will have more 
security bugs than Windows NT 4.0 and Windows 98 combined.  In its defense, 
Microsoft has claimed that it spent 500 people-years to make Windows 2000 
reliable.  I only reprint this number because it will serve to illustrate 
how inadequate 500 people-years is.

The networks of the future, necessarily more complex, will be less 
secure.  The technology industry is driven by demand for features, for 
options, for speed.  There are no standards for quality or security, and 
there is no liability for insecure software.  Hence, there is no economic 
incentive to create high quality.  Instead, there is an economic incentive 
to create the lowest quality the market will bear.  And unless customers 
demand higher quality and better security, this will never change.

I see two alternatives.  The first is to recognize that the digital world 
will be one of ever-expanding features and options, of ever-faster product 
releases, of ever-increasing complexity, and of ever-decreasing 
security.  This is the world we have today, and we can decide to embrace it 
knowingly.

The other choice is to slow down, to simplify, and to try to add 
security.  Customers won't demand this -- the issues are too complex for 
them to understand -- so a consumer advocacy group is required.  I can 
easily imagine an FDA-like organization for the Internet, but it can take a 
decade to approve a new prescription drug for sale, so this solution might 
not be economically viable.

I repeat: complexity is the worst enemy of security.  Secure systems should 
be cut to the bone and made as simple as possible.  There is no substitute 
for simplicity.

Unfortunately, simplicity goes against everything our digital future stands 
for.


** *** ***** ******* *********** *************

              Comments from Readers



From: Shawn Hernan <svh@cert.org>
Subject: Full Disclosure

I was intrigued by your recent series of editorials in Crypto-Gram 
regarding full-disclosure, and especially, CERT.  I am writing to respond 
to the article.

Some of your criticisms of CERT are valid, and I agree with them; but I 
wanted to point out a couple of things that you may not realize about our 
current practices.

When deciding what to publish and when, we use a variety of different criteria.

First, whatever we publish has to be *true* -- we go to great lengths to 
validate and verify everything we say in an advisory, and you can imagine 
some of the arguments that ensue over what is "true."

Second, as a rule of thumb, our advisories are generally about very serious 
problems.  We have a formal metric that we use to attempt to put 
vulnerabilities on a linear scale of "severity" and we use that as a 
first-order estimate of the gravity of the problem, and use our experience 
as the final judge.  Generally, the problems issued in advisories are in 
the 90th percentile of this scale (internally called the "threat metric").

Third, although it may have been true in the past, it has never been the 
case in my time here (about 4 years now) that our publication schedule was 
dependent on all (or even any) of the fixes being available.  We certainly 
prefer to have fixes available at publication time, but if we discover that 
a vulnerability is being exploited we will publish regardless of the 
availability of any fixes or patches.  My team (the vulnerability handling 
team) works very closely on a daily basis with the incident response team 
to understand if a vulnerability is being exploited.

Given all that, I am trying to find responsible, practical ways to publish 
more information about vulnerabilities in a variety of forms.  We are a 
relatively small organization, and I'm not willing to sacrifice truth for 
expediency.


From: Ryan Russell <ryan@securityfocus.com>
Subject: Distributing Exploits

You're still not totally consistent in what you say:

  >Third, I believe that it is irresponsible, and possibly
  >criminal, to distribute exploits.

You've already acknowledged that that's what it takes to get action.

  >Reverse-engineering security systems, discovering
  >vulnerabilities, and writing research papers about them
  >benefits research; it makes us smarter at designing secure
  >systems. Distributing exploits just make us more vulnerable.

You acknowledge your behavior being inconsistent with your words, which is 
neither here nor there.  It not only often takes an exploit, but it takes a 
press release sometimes.  Thievco released an "exploit" to decode Netscape 
passwords a year and a half ago.  Netscape did nothing.  RST Corp. did the 
same, with a press release.  That got Netscape's attention.

  >For example, Mixter is a German hacker who wrote the
  >Tribal Flood Network tool used in some of the distributed
  >denial-of-service attacks. I believe he has a lot to answer
  >for. His attack tool served no good.

Not true.  Were it not for him, we'd probably be looking at mystery tools 
that were being used that we didn't have the source for, and couldn't as 
easily analyze.  Mixter has combated much FUD by showing us exactly the 
type of thing that can be used, so that the reporters couldn't run off and 
tell the public that the evil hackers have superweapons the security 
experts know nothing about.

  >It enabled criminals and cost a lot of companies a lot of
  >money. Its existence makes networks less secure.

As you say, like any tool, it enables both good and bad guys.  As you've 
pointed out, the security problem was already there, the tools just 
highlight it.

Let me speak to the subtext of your rant against Mixter.  Some people think 
Mixter may deserve some punishment.  I don't, but I can see some of the 
logic.  Really, I think if anyone deserves punishment, it's the guys who 
used the tool.

Did Mixter and even the attackers actually do anything in the spirit of 
full disclosure?  Yes.

We've been complaining for years about the spoofing problem, and expecting 
ISPs to do filtering.  Nothing has happened.  Mixter put out his 
tool.  Some meetings to discuss DDoS happened.  No actual change to 
behavior, but there was some amount of advanced planning, which was good 
preparation.  Finally, some person (yes, criminal) put their neck on the 
line and actually used them.  They didn't take down the security sites to 
make them look bad.  They didn't go after the government.  They went after 
e-commerce, which I have to assume was designed for maximum reaction.

I think we'll get some action now.


From: Brian Bartholomew <bb@wv.com>
Subject: Publishing exploits

  > Second, I believe in giving the vendor advance notice.  CERT took
  > this to an extreme, sometimes giving the vendor years to fix the
  > problem.  I'd like to see the researcher tell the vendor that he
  > will publish the vulnerability in a month, or three weeks (no fair
  > giving the vendor just seven days to fix the problem).  Hopefully
  > the vulnerability announcement can occur at the same time as the
  > patch announcement.  This benefits everybody.

Whatever CERT's motivations were, they had the effect of increasing user 
trust (because a new sheriff is in town) while decreasing trustability 
(because they sat on vulnerabilities users handed off to them).  This is 
backwards, in two places.

I prefer the following approach: announce existence of vulnerability and 
promise a kiddy script in a month; wait a month for vendor to react; 
publish kiddy script.

  > Publishing vulnerabilities in critical systems that cannot be easily
  > fixed and whose exploitation will cause serious harm (e.g., the air
  > traffic control system) is bad.

Publishing is *very important* in these cases so the stakeholders know to 
reduce their trust in these systems.  If air traffic control is vulnerable, 
tell me so I can stop taking airplanes!

A non-life-safety version of this problem was the publishing of a script 
that gave an existing process root privileges using the memory debugger 
abilities of the console monitor ("L1-A") of a Sun.  This debugger could be 
disabled, but nobody did because it disabled the software reset 
button.  This reported vulnerability allowed users to adjust their trust of 
the security of root sharply downward, corresponding more closely to the 
actual security of it in practice.

  > Third, I believe that it is irresponsible, and possibly criminal, to
  > distribute exploits.

This is gun control: "Don't punish murder, ban the gun instead!  Exploits 
are an evil instrumentality!  Exploits help a good boy go bad!"  The right 
answer is: Humans are held responsible for their behavior.  Guns, bricks, 
and exploits are just tools.


From: Greg Guerin <glguerin@amug.org>
Subject: publicity attack loops?

I have to admit that I was chuckling all the way through the 
Fernandes/Cryptonym letter in the Feb 2000 Crypto-Gram.  Especially when at 
the end he wraps himself in the mantle of professional integrity.  I've 
already written two essays on the Fernandes discovery and his downloadable 
"repair" ZIP:
    <http://amug.org/~glguerin/opinion/win-nsa-key.html>
    <http://amug.org/~glguerin/opinion/crypto-repair-kit.html>

Though neither one is about Fernandes's professional integrity, per se, 
they do make a number of points about specific practices.  To summarize the 
points (see the essays for the full explanation):

    1) the ZIP held 2 EXE's, 2 DLL's, and 1 source file.
    2) the downloadable ZIP had no digital signature.
    3) nothing within the ZIP had a separate digital signature.
    4) Fernandes's PGP key had no introducers at all.
    5) no pointers to others who could vouch for points 2-4.
    6) source was not compilable as supplied (missing header).

Point 6 is only a little important because it means the EXE's must be 
trusted as given.  But there was only one source file anyway, so you're 
already trusting the other EXE completely.  And both DLL's must be trusted 
completely.  Risk-wise, 75% blind trust is virtually identical to 100% 
blind trust, so it's not all that useful a distinction.  It's like choosing 
whether to kill something 3 times over or 4 times -- correctly killing it 
once suffices.

Note that at no point does "professional integrity" come into this, only 
"professional practice".  I'm not disputing INTENT (integrity), I'm only 
describing OUTCOME (practice).  Spotless integrity and intent cannot long 
survive avoidable errors in practice.  By observing practices an observer 
might infer skill, integrity, or both, or neither.  Those judgements, and 
the trustworthiness criteria underlying them, are left completely to the
particular observer.  All I can say is what I would infer from my 
observations, and why.  You should draw your own conclusions, since my 
criteria for trustworthiness may differ from yours.  But you should also 
invest in understanding why you came to those conclusions -- flaws in the 
process can lead you astray.


From: "Rolf Oppliger" <rolf.oppliger@esecurity.ch>
Subject: Distributed Denial-of-Service Attacks

First of all, I'd like to congratulate you for your description and 
analysis of distributed denial-of-service (DDoS) attacks in the February 
issue of your Crypto-Gram newsletter.  I fully agree with most of your 
statements, including your pessimistic view that all existing approaches to 
address the problem are unsatisfactory in one way or another.

In your article, however, you also argue that "in the long term, 
out-of-band signaling is the only way to deal with many of the 
vulnerabilities of the Internet, DDS attacks among them."  I don't agree 
with this statement.  Any out-of-band signaling channel can also be 
subjected to DoS and DDoS attacks.  I believe that the reason why telephone 
networks are not subjected to large-scale DoS and DDoS attacks is due to 
the fact that they address charging and billing, rather than their use of 
out-of-band signaling (out-of-band signaling has many advantages in other 
areas).  Trying to establish a huge quantity of connections in a telephone 
network is simply too expensive ... I think that the lesson learnt from 
telephone networks is that packet-based charging and billing -- combined 
with adequate security mechanisms -- may be a viable solution to protect 
against large-scale DoS and DDoS attacks on the Internet (rather than 
out-of-band signaling). However, packet-based charging and billing also has 
many disadvantages, including, for example, a huge administration 
overhead.  Consequently, I guess that packet-based charging and billing 
will not be applied on the Internet, and that "intelligent" 
packet-filtering performed by ISPs will be the major weapon to protect 
against large-scale DoS and DDoS attacks in the future.


From: Ethan Benatan <benatan@duq.edu>
Subject: Defending Against DOS Attacks: Draining the Swamp

If you'll pardon the musings of a biologist, I'd like to comment on your 
swamp analogy.  I know you never stated so but it bears pointing out that 
swamps are not "bad" in any defensible sense, nor is draining them "good," 
even though doing so may have one immediate desirable consequence.  I am 
sure that in your own field you can think of many examples where a cure, 
though effective, may have been worse than the disease.  The RISK here is 
forgetting that in any complex system change comes at some cost; the more 
complex (or less well understood) the system, the harder it is to predict 
the cost.  I think this applies to the Internet.  It certainly applies to 
the natural world, in spades.  I will not bore you with examples.


From: pclites@cdsfulfillment.com
Subject: deCCS

In the February 2000 Crypto-Gram, you wrote: "An important point is that 
DVDs can be copied and pirated without using deCSS or any other decryption, 
which certainly makes the original claim of 'prevents piracy' look either 
astoundingly ignorant or brazenly deceptive."

There is a sense in which the "prevents piracy" claim makes sense.  deCSS 
makes it easy to copy the data on a DVD not just onto another DVD, but into 
another format, one which is easier to copy & transmit.  In that sense, one 
could characterize it as making piracy easier.  Kind of like the rationale 
behind the distinction between printed & electronic versions of source code 
in the original crypto export restrictions; but for a consumer data 
product, I think it's a more meaningful distinction.  I would have to 
characterize the court's ruling as a correct application of a bad law, in 
what may turn out to be a watershed case.


From: "Bryan Alexander" <xande1@bellsouth.net>
Subject: Secure Linux

  > The NSA has contracted with Secure Computing Corp. for
  > a secure version of Linux.  Personally, I don't know if
  > the Linux license allows the NSA to make a secure version
  > of the operating system if they are not going to freely
  > distribute the results.

Actually the GPL (Gnu Public License, which covers almost all parts of 
Linux) does allow this.  There is no language in the license that requires 
that you redistribute anything based on the GPL, only what you are required 
to do *if* you redistribute a work based on the GPL.  In addition, the GNU 
Project has said specifically that the license is not intended to prevent 
people from creating (without being forced to distribute) their own 
modified versions of GPLed software for their own use.  The text of the GPL 
is located at: <http://www.gnu.org/copyleft/gpl.html>.

A statement about being forced to distribute modified versions of software 
being an "unacceptable restriction" can be found at 
<http://www.gnu.org/philosophy/apsl.html> under the heading "Disrespect for 
Privacy."  This is part of a discussion of the "fatal flaws" in the Apple 
APSL license.  (I can't find the original source for the comment about this 
as it relates to the GPL right now, sorry.)


** *** ***** ******* *********** *************

CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, 
insights, and commentaries on computer security and cryptography.

To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a 
blank message to crypto-gram-subscribe@chaparraltree.com.  To unsubscribe, 
visit http://www.counterpane.com/unsubform.html.  Back issues are available 
on http://www.counterpane.com.

Please feel free to forward CRYPTO-GRAM to colleagues and friends who will 
find it valuable.  Permission is granted to reprint CRYPTO-GRAM, as long as 
it is reprinted in its entirety.

CRYPTO-GRAM is written by Bruce Schneier.  Schneier is founder and CTO of 
Counterpane Internet Security Inc., the author of "Applied Cryptography," 
and an inventor of the Blowfish, Twofish, and Yarrow algorithms.  He served 
on the board of the International Association for Cryptologic Research, 
EPIC, and VTW.  He is a frequent writer and lecturer on computer security 
and cryptography.

Counterpane Internet Security, Inc. is a venture-funded company bringing 
innovative managed security solutions to the enterprise.

http://www.counterpane.com/

Copyright (c) 2000 by Counterpane Internet Security, Inc.