[254] in Release_7.7_team
Re: telnet -safe as default
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Jan 15 00:01:30 1995
To: jhawk@MIT.EDU
Cc: cfields@MIT.EDU, ghudson@MIT.EDU, release-team@MIT.EDU, brlewis@MIT.EDU
In-Reply-To: Your message of "Sat, 14 Jan 1995 23:48:43 EST."
<199501150448.XAA01133@lola-granola.MIT.EDU>
Date: Sun, 15 Jan 1995 00:01:35 EST
From: Greg Hudson <ghudson@MIT.EDU>
> No. I'm saying that I expect that eventually (I suppose I neglected
> to submit my bug report to anyone other than Athena; I will rectify
> this when I finish my development work on telnet over IAP...) the
> "mainline" (i.e. K5 and CNS K4) encrypted telnets will support my
> change of -ax failing when an encrypted connection is not possible.
I think this would be poor. It raises several issues:
* What if I just specify -a?
* What if I just specify -x?
* What if I want a single command that obtains the most secure
connection possible?
* What if we want to make that the default behavior?
* What if I'm used to using "telnet -ax" as such a command (as
per the documentation), and the behavior of telnet changes
on me?
I think the right approach is to have an option which specifies that
telnet should fail if it does not achieve all the requested security
options. Let's call this option "-s", since it's not taken (except by
"-safe", which breaks option-parsing semantics anyway). Then "telnet
-as" will fail if it can't authenticate, "telnet -axs" will fail if it
can't authenticate and encrypt, etc..
Alternatively, we can go with my earlier proposal of having telnet
-safe have the distinguished meaning of "-ax plus no fallback".
