[251] in Release_7.7_team
Re: telnet -safe as default
daemon@ATHENA.MIT.EDU (jhawk@MIT.EDU)
Sat Jan 14 12:15:00 1995
From: jhawk@MIT.EDU
Date: Sat, 14 Jan 1995 12:14:51 +0500
To: ghudson@MIT.EDU
Cc: cfields@MIT.EDU, release-team@MIT.EDU, brlewis@MIT.EDU
In-Reply-To: "[250] in Release_7.7_team"
Greg Hudson (quoting me):
> > I would recommend that a new option be added, perhaps -A or somesuch
>
> I could not find the bug chain you referred to,
Those were Netprob bugs. The discuss transactions begin with [12701]
in Athena Bugs.
> but I see no reason why "telnet -safe" should be equivalent to
> "telnet -ax", or why "telnet -ax" should fail if confronted with a
> system which does not support authentication:
The original issue was that telnet -safe and telnet -ax, both
of which exhibit the same behavior, lull the user into the false
assumption that whenever you type
telnet -ax hostname
or telnet -safe hostname
you are going to get an encrypted connection, and it's fine to
type your password. It's *VERY* misleading to not say anything
on a machine where there is no encrypted connection. Sure, the
astute user will notice it doesn't mention:
[ Trying KERBEROS4 ... ]
[ Kerberos V4 accepts you ]
[ Kerberos V4 challenge successful ]
But that's no good to the person who isn't paying a whole lot
of attention. (Cf. 12701 et al)
[citing language from the man page]
> The language "attempt" and "if possible" suggests that fallback
> behavior is appropriate; I don't see any reason to change this.
I am arguing from the perspective where the docs are NOT the reference
point. We should change the behavior and then change the docs
to reflect that. (Isn't moral ground great?)
> I suggest that "telnet -safe" be treated differently from "telnet
> -ax", and that "telnet -ax" be the default behavior. The
> documentation for -safe should be changed from:
>
> -safe For MIT Athena, this option is equivalent to -ax.
>
> to:
>
> -safe For MIT Athena, this option attempts automatic login with an
> encrypted data stream, and fails if this is not possible.
This, again, is poor. It causes the user who types telnet -safe to
be mislead into thinking they're getting an encrypted connection, when
maybe they are not.
As for the counterargument, that telnet -ax should allow this behavior,
that's bogus too, since lots of people type it (because it's shorter),
and more importantly, telnet -ax exists outside of the Athena environment
(44BSD, CNS's next release, Cray telnet), and shouldn't be monkeyed
with...
Whew. Incidently, for those of you interested, J.I. is in town and he
mentioned he'll be working on D-H encrypted telent soon...
--jhawk
