Re: Testing for UTF-8 tty mode

[Frank da Cruz <fdc@watsun.cc.columbia.edu>]

Markus Kuhn wrote:
>
> Can telnet pass the information that we prefer UTF-8 along? Or is telnet
> already obsolete (it was forbidden everywhere where I worked over the
> last 3 years, as the world has now moved almost completely to ssh
> apparently due to password sniffers.)
> 
Telnet is most emphatically not obsolete.  There is a misconception among
Linux users that ssh is the answer to all problems.  I don't mean to start a
war here, but I think it should be stated openly that ssh is not necessarily
the cure-all that many believe it to be:

 1. Public-key authentication is fine for isolated situtations, but not
    for large organizations like universities where key management and
    revocation become an important issue, e.g. when a password becomes
    compromised.  In such settings we need a centralized, secure,
    seriously managed authentication database.

 2. Many forms of Telnet security are available, including Kerberos IV 
    and V, SRP, TLS, etc, all of which are better suited to large
    organizations.

 3. United States law regarding distribution of strong encryption to
    noncitizens (e.g. students from other countries) would seem to forbid
    the universal use of SSH on USA campuses (this is controversial; legal
    opinions are divided).

 4. The patent held by RSA on SSH's encryption algorithm requires a
    license for use in any setting where money changes hands.

 5. There might also be some licensing requirements from Data Fellows 
    for the SSH clients themselves.

 6. SSH V1 is "dead" but SSH V2 is not finished yet.

It is highly probably that many if not most SSH clients in use today, at
least in the USA, have been distributed in violation of one or more US laws,
patents, and/or copyrights.

The Kermit telnet client implements all the forms of security mentioned
above, but due to the bizarre situation with US export law, we can't make
the security aspects of the software available except under controlled
conditions that prevent it from escaping the USA and Canada.  The laws might
be stupid, but they are laws.  (SSH clients tend to come from countries
where US laws don't apply.)

There is also the question of functionality -- to my knowledge, ssh clients
don't incorporate character-set translation, scripting, file transfer, etc.
(How many ssh clients are there and how many Telnet clients?  Anybody can
write a Telnet client and include any desired features -- the same is not
true for ssh.)

Returning to the question at hand...  I am not aware of any Telnet protocol
to negotiate character sets, although there was once an Internet Draft on the
subject.  I argued against it for a long list of reasons that I can provide
if anybody is interested -- the main one being that a Telnet session might
be only one piece of the end-to-end connection, and it has no knowledge of
what the other pieces are, or for that matter, what the connection is being
used for.  For example, if a ZIP file is being transferred over the
connection, we don't want the Telnet partners changing its bytes.

Only the human user knows exactly what character-set translations are needed
at any particular point in a session.  I might have a Telnet connection to
some kind of hub that collects text in many languages and character sets.
Since no operating system on earth records the encoding (character-set) of
a text file as a property, it falls upon the user to push buttoms to get the
right combination. 

In any case, the Kermit Project is deely involved in the development of
Telnet clients, with special attention to character sets AND security, and
the IETF Telnet working group is quite active, and is currently editing the
many Telnet security drafts & RFCs into a more-or-less coherent whole.

- Frank
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/