See also: last week's Letters page.

Letters to the editor

To: ylo@ssh.com, letters@lwn.net
Subject: Your legal threats concerning the SSH trademark
Date: Wed, 14 Feb 2001 13:06:01 -0500 (EST)
From: Don Barry <don@astro.cornell.edu>

Dear Mr. Ylonen,

First, I wish to thank you for designing the first SSH protocol and 
working with international standardization bodies to create what is now
an official as well as unofficial standard for secure communications between
computers.  I also thank you for beginning this effort under an open 
source license, which I hope you realize was an essential part of your
contribution being accepted as a standard.

Now to the criticism.  I was very disappointed when you took your product
in a commercial direction: I frankly found it a predatory maneuver to 
establish a project in an open source manner and then proprietize it after
having it accepted as a standard.  I gave you the benefit of the doubt and
presumed this behavior was accomplished by business denizens who by then 
controlled the destiny of your company.

I see now that I was wrong.  Even if my original presumption was 
correct, by lending your own name now to a legal effort to throw confusion
into the arena of SSH protocol products, you have confirmed the worst 
suspicions of many of us.

Actually, I find essentially all users of SSH and OpenSSH are quite clear 
about the origins and distinctions between these programs.  The downturn
in your commercial fortune is not due to a "confusion" between these two
products -- it is in fact due to a *recognition* that the open source
version is superior, and the desire of users to not choose a product 
offered by a developer and company which has shown erratic and greedy 
behavior in the past.  Frankly, I wish they had developed this product
in the GPL fashion, because this *free source* technique is even superior
and would prevent would-be pirates (like you are free to do) 
from generating proprietary code forks.

The confusion and doubt which you mention is not in the use of the OpenSSH
designation to describe a well-known code base, it is actually your attempt to
generate confusion among those who would use the open alternative to your
product, by obfuscating its identity.

Finally, your statement claiming fundamental insecurities in the 
SSH1 compatibility mode of the OpenSSH product (something, I might add, now
offered by your *own* product after a failed attempt to do a full proprietary
transition) is a classic example of Fear, Uncertainty, and Doubt in action.
The theoretical vulnerabilities of the SSH1 protocol to insertion attacks
would prove extremely difficult to mount in practice, and the actual 
CERT vulnerabilities you mention deal with more mundane affairs such as
buffer overflows -- something your *own* product has also suffered from.
These real-world vulnerabilities are of course the primarily exploitable ones,
and are a factor of the quality of the code base, not the algorithms.
And, of course, the OpenSSH software does implement both SSH1 and SSH2 
protocols.

In my own academic capacity, I have succeeded in impressing on my colleagues
the importance of using secure communications in our activities.  We use
both the SSH and OpenSSH codes in my department.  If you wish to compete in this
arena, do it through the creation of superior software, preferably in the
open (or better yet, *free*) domain, and not through legal maneuvers.
Henceforth, should you not choose a more moderate and cooperative path in
working with the community of coders producing for the public good, I will do my
best to make sure that your product is found on not one of our machines, and
that people know exactly the reason why.

Cheers,

Don Barry, Ph.D.
Space Infrared Telescope Facility Team
Cornell University

To: letters@lwn.net
From: Jim Dennis <jimd@starshine.org>
Subject: Tatu Ylonen's message to the OpenSSH developers
Date: Wed, 14 Feb 2001 17:16:23 -0800


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


 I personally applaud Tatu Ylonen's restraint and tact in his message
 to the OpenSSH developers list.  I think it's long overdue.

 It's a pity that SSH(TM) isn't completely free.  It's a pity that
 Tatu hasn't found a revenue model that would allow him to release
 under the GPL or BSD licenses, or to create a DFSG compliant license.
 Obviously, revenue models are a hard problem for free software -- and
 some people do need to live off their programming labors.  I can't
 begrudge Tatu (or others) that.

 However, it's equally a pity that no one has come out with a fully
 independent protocol compatible re-implementation.  Tatu published
 his sources, and a full description of the protocols (both versions?) 
 and has actively encouraged (through his participation in the IETF)
 an independent implementation.  (IETF guidelines strongly suggest,
 nigh onto *require* multiple independent and interoperable
 implementations of all new Internet standards).  lsh/psst
 (http://www.net.lut.ac.uk/psst/) seems to be a moribund project; the
 fact that it hasn't even become available as a Debian package in
 unstable is testimony to that.

 (I also think that it's a pity that SSH(TM) and its ilk are still
 necessary.  Unfortunately the deployment of IPSec and especially
 secure DNS still lags to the point where opportunistic encryption and
 transparent authentication are still distant dreams).

 Unfortunately I think that Tatu will be castigated for his message
 and I'd like to go on record as saying that all the complainers
 should stuff it!  Go help Martin Hamilton and the rest of the psst
 team if you insist a fullly GPL version of an ssh(TM) compatible
 package.  (Or help get InterNIC to adopt a secure DNS version of BIND
 *and* to publish keys and sign their top level zone data --- and
 otherwise help us realize IPSec).

 Meanwhile the OpenSSH [sic] team should probably consider renaming
 their package OpenSecsh (possibly to be pronounced like a drunk
 commenting on "promiscuous sex").  I suspect that Tatu would have no
 complaint about their use of the IETF name for the protocol --- and
 he hasn't even asked them/us to change the name of the binary.

 I'd, nonetheless recommend that they/we rename the binary, and
 include a wrapper script called ssh that does something like
 reasonable.  ( Something like:

	    #!/bin/sh
	    echo "SSH is a trademark of SSH Inc and Tatu Ylonen" 2&>1
 	    /usr/bin/secsh "$@"


	... or a C binary wrapper to that effect; would suffice.

 Acknowleging the author and trademark holder when calling the program
 under it's traditional name seems appropriate and anyone who thinks
 this onerous (or finds that it's causing their scripts to break) can
 simply make their own alias or wrapper, or change to the new name.

 Tatu (copied on this), thank you for your patience and tolerance in
 this matter. Also, I'd like to thank you for writing an indispensable
 piece of software that has truly made the Internet safer.  The thing
 that will help further is its continued development, the accelerated
 demise/upgrade of the obsolete versions, and more ubiquitous use.

- --
Jim Dennis               
Software Analyst		
Axis Personal Trainers			http://www.axispt.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>

iEYEARECAAYFAjqLLd0ACgkQIGV97BI+xjGUjgCfZV+K5nyOQhLFvQIoXiqdAJYA
IuMAn2UkVoFWDTZZNYcj2Q1lFZ6V2fcc
=dZ7F
-----END PGP SIGNATURE-----

Subject: HTML email privacy
To: editor@lwn.net
Date: Thu, 8 Feb 2001 13:51:04 +0000 (GMT)
From: Alan Cox <alan@lxorguk.ukuu.org.uk>

The article you point to on html email privacy is actually quite misleading.
Disabling javascript will not protect against most email privacy attacks.

A simple 

	<IMG src="http://evil.mailtracking.scum.org/cgi-bin/track?id=123456">

type tag will allow the tracking of the host used to read each email. The
information that most browsers will hand back generally provides the ip
address and other basic system factors (including monitor size with some
browsers).

It is also possible to use the rlogin: URL to extract usernames from browsers
because the rlogin client will pass username information as part of the 
connection setup. From this and the IP address you can normally deduce an
awful lot about the user.

No javascript required.

Alan

From: Hubert Tonneau <hubert.tonneau@heliosam.fr>
To: letters@lwn.net
Subject: DNS servers list: Pliant is missing
Date: Thu, 08 Feb 2001 11:05:49 GMT

In february the 8th issue of LWN, you listed several alternatives to Bind,
but forgot Pliant (http://pliant.cx/)

Pliant DNS server is:
. released under GPL,
. very compact (less than 1000 lines)
. using Pliant database engine for reliably storing configuration files
. remotely administrated using a web browser over Pliant strong crypto
  secured channel.

It's not suited for first level domains such as (.com or .fr), but for
hosting second level domains of your compagny or your organization
(pliant.cx or heliogroup.fr), it should work just fine.
Of course, it can also act as a caching DNS for your site or your computer.

Regards,
Hubert Tonneau

From: Russell Nelson <nelson@crynwr.com>
Date: Thu,  8 Feb 2001 10:46:03 -0500 (EST)
To: lwn@lwn.net
Subject: not true


   From the above list, one can conclude that BIND's competitors have
   some ground to cover yet. Energetic hackers looking for a project may
   want to consider the creation of a viable competitor to BIND; the net
   will be a safer place when we have one.

Why?  djbdns is a viable competitor to BIND.  The author's personality
is irrelevant to the quality of the software, the author considers
your inability to redistribute modified versions to be a feature (and
given the track record of some vendor-modified versions of sendmail
and bind, he's got a point), and the code is only difficult to read
because it uses many functions from Dan's library.  Said library by
design discourages buffer overruns.  Did I mention that it discourages
buffer overruns, which are irresponsible for 50% of all Unix security
lapses?  It's not C, it's the C library.

And djbdns could serve the .com zone using 3GB of memory, as opposed
to the 8GB used by ISC's root zone server.  Is that a large enough
zone for you?

-- 
-russ nelson <sig@russnelson.com>  http://russnelson.com
Crynwr sells support for free software  | PGPok | "This is Unix...
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Stop acting so helpless."
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | --Daniel J. Bernstein

Date: 8 Feb 2001 10:09:49 -0000
From: cpb@log2.net
To: letters@lwn.net
Subject: Asbestos for you

On the LWN front page of Feb. 8, 2001, you state that the djbdns DNS server
"lacks some capabilities (TCP service, zone transfers, ...), making it not
necessarily suitable for larger domains."

Please print this email on asbestos and add it to the truckload of asbestos
you will need should someone with more knowledge of djbdns and the desire
to demonstrate that knowledge choose to come after you with email flames!

I have the knowledge, but not the desire.                   - Chris Bopp

P.S. If djb himself writes, you will need more than a truckload!

Date: Thu, 8 Feb 2001 08:54:12 +0100
From: Frank Tegtmeyer <fte@fte.to>
To: lwn@lwn.net
Subject: errors about djbdns on your front page

Hi,

while I am glad you mentioned djbdns as a secure alternative to
BIND, I have to point out at least two errors:

"djbdns also lacks some capabilities (TCP service, zone transfers, ...),
making it not necessarily suitable for larger domains."

djbdns (formerly dnscache) contains axfrdns since January 2000. Therefor
your statement about TCP and zone transfers is not true and has to be seen
as misinformation. Making these false statements you come to the conclusion
that djbdns is "not necessarily suitable for larger domains". This is
ridiculous and not backed by any facts.

I invite you to join the djbdns mailinglist and ask for large companies
using djbdns or for ISP with a big number of zones using djbdns.

The point is that djbdns doesn't lack features of BIND - it is simply
different. You have to stop "BIND thinking" when handling djbdns.
I agree that you can get into some trouble because of the mentioned
"monoculture" at the Internet today when using djbdns. But there
are enough people using djbdns that prove your statements wrong.
I expect the necessary corrections at your page.

With kind regards,
Frank Tegtmeyer

Date: Thu, 8 Feb 2001 19:05:45 -0500
From: "Jay R. Ashworth" <jra@baylink.com>
To: letters@lwn.net
Subject: DJB and his DNS

In the special on djbdns, the editor wrote:
> In the end, though, you need not like Mr. Bernstein to make good use
> of his software.

That's a comforting assertion, but I'm not sure whether it's correct or
not.  I can see many reasons why the attitude of a software package's
maintainer is a pertinent issue in selecting what you're going to
deploy in your network, be that network 2 machines or 200,000.

Even in the free software world, it would seem to be an issue.  While
the old "you have the source, you can fix your own problems" argument
will surely be made here, of course, it's not true for everyone:
especially something as hirsute as a DNS server is not code that
everyone will be able to do anything with.

One of the projects that I'm involved with (when I can find time and
manage not to be ill) is the open fax server software system HylaFAX,
originally written by Sam Leffler when he was at Silicon Graphics, and
now available under a reasonably open license (I believe it's either
strict or slightly modified BSD).  <http://www.hylafax.org>

While the package has a fairly decent sized user community -- frankly,
we don't know how big it is because most of the installations Just Work
:-) -- finding good developers who can work on it is hard.

That's because it's a) soft-real-time code and b) written in C++.

We're lucky to have the 4 or 5 people we do, when they can spare the
time, but it sure wouldn't hurt if there were a few more.

What *is* safe to say, though, based on the support queries I see on
our user mailing list, is that the vast majority of the people who
{are,would like to be} deploying it are *not* equipped to do more than the
slightest little bit of hacking on it around the edges.  And there's
nothing wrong with that; in fact, it's essential.

Luckily, the development community on this project, headed by Mr.
Arlington Hewes, is much more personable and easy to get along with
than DJB is reputed to be (I've never worked with the man, but I heard
the sparks around the edges of maildir format support when I was on the
mutt-devel list.)

So perhaps, just having good code *isn't* enough; we geeks are going to
have to come out into the real world, too.

Damn.

What a shame.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

Date: Thu, 8 Feb 2001 21:08:55 +0000
From: Alain Williams <addw@phcomp.co.uk>
To: lwn@lwn.net
Subject: The case for competition

I will not labour the well sung refrains that competition is good because:
it leads to the evolution of good solution(s); heterogeneity engenders
robustness in the face of cracking attacks; choice for the solution that is
right for you; ...

There seems to be a curious belief that everyone involved in Open Source
is, somehow, supposed to be working together, that we are all part of some
big global organisation or company. That belief naturally leads to the
assertion that different (but similar) Open Source projects are really
branches of this one organisation are competing/working against each
other. The mental analogy is as if different departments in
IBM/Microsoft/...  worked to produce competing: word processors, compilers,
...

There is also the reinforcing notion that if it comes from one
organisation, then it was all written by that place. People see Linux as
being an organisation, and so think that the different Linux distributions
are probably something to do with the supply chain; putting a slightly
different badges on *one* product made by some higher up company.

The idea of software being produced by a ``for profit'' company is deeply
ingrained. One frequent question that I get asked is something like: ``If
it is given away how does Linux pay for the development ?''. The idea of a
community sharing resources seems hard to grasp.

With this one company gestalt it is hardly surprising that competing
projects (be that desktops or MTAs) are seen as a flaw in the Open Source
``business'' model. These same people would have no problem in accepting
different companies competing to produce the better product and so gain
market share and so, presumably, profit. Most people don't understand the
Open Source ``business'' model. Whereas a conventional business survives by
competition, Open Source survives by cooperation.

Another problem is that many people do not like choice. They just want to
know ``the way to do XXXX'', if there is choice then they need to think,
and most people don't want to think about the choices in how to use
computers -- this is not a derogatory remark, it is recognition that for
most people a computer is a tool with which to do a job; for most people
that is the right attitude.

But people love choice when it comes to cars, refrigerators, video
recorders; so why not computer software ? I think that one big reason is
the learning effort that goes into changing the computer software that you
use. The learning effort for changing the other things is trivial; well,
maybe I was wrong to talk about video recorders - but you get the idea.

In summary: we, the technical community, have to beware trying to judge
other people's view of us (and our actions) from our own points of
view. Let us try to see ourselves as others see us; if we don't like what
we see then maybe we need to change the way that we present ourselves (and
our passions) to the rest of the world. Ie we need to learn to communicate.

-- 
Alain Williams

Date: Thu, 8 Feb 2001 14:05:12 -0600
From: David Fries <dfries@umr.edu>
To: letters@lwn.net
Subject: proving compliance

Lets say you or your company does go with GPL or free software.  How
do you prove that?  I think it is harder than it sounds.  It is easy
for them to say you have software you can't show a license, but it is
a harder job to show you don't have the software.  What are they going
to go though every megabyte on your drive and make you decrypt all
data?  

I'm for free software, but I don't think it will prevent a raid and is
there any way for someone to get back at them for disrupting a
business that is in compliance?

-- 
		+---------------------------------+
		|      David Fries                |
		|      dfries@umr.edu             |
		+---------------------------------+