[259] in Release_7.7_team
Re: telnet -safe as default
daemon@ATHENA.MIT.EDU (cfields@MIT.EDU)
Wed Jan 18 02:46:42 1995
From: cfields@MIT.EDU
Date: Wed, 18 Jan 1995 02:45:40 -0500
To: release-team@MIT.EDU
Cc: krb-apps@MIT.EDU, brlewis@MIT.EDU, ghudson@MIT.EDU, jhawk@MIT.EDU
[This is continuing in release-team because I am forcing it as a
release issue. I'm not interested here in discussions on how
security should work in the ideal world, or how we should have it
eventually. I'm worried about here and now, which unfortunately
have a different set of priorities.]
Possible behaviours:
1. No encryption; don't even try
2. Encryption, but if you can't get it, fall back.
3. Encryption, but if you can't get it, fall back, warning
the user there is no encryption.
4. Encryption, and if you can't get it, die.
Currently,
default = 1
-safe = 2
-ax = 2
I propose:
default = 2
-safe = 4
-ax = 2
-old = 1 (new option)
On safe = 4:
I agree with the idea that "safe" should mean what it says,
and not "safe, well, maybe." I don't see any particular reason
not to provide this functionality as a special option here at,
MIT, distinct from "-ax." Since we bothered to add it in the
first place, we ought to make it consistent with its name.
Unless we want to call it "telnet -safer."
On ax = 2:
I don't care to speculate on what future behaviours of -ax
might be in various telnet implementations. As I understand it,
2 is the behaviour that exists now, and I don't think we should
change the behaviour of existing command line options. If in
the future -ax changes to 4, then we change change ours then
to follow suit (with the usual documentation issues).
On default = 2:
Clearly, the default behaviour should not prevent normal
telnetting from working; therefore a fallback is appropriate.
At the same time, we have people snooping our net and plenty
of users who aren't actually bothering (for whatever reason)
to add the current "-safe" to their command lines. It is in
both our and their interests to get them using this code one
way or another, and I think default = 2 is the ideal way to
handle this.
On old = 1:
All I have in mind here is a way to provide the old behaviour
in an option. I haven't actually thought much about the best
way to do that. This is not likely to be it.
I don't ever go for behaviour three because I don't want to create the
_expectation_ of the user that if encryption isn't happening, they
will be warned of it, because they may take it to other sites and get
burned. This may or may not be worth being concerned with.
In any case, I do think that various other changes would be a good
idea. I just don't think it's wise to make them in incompatibility
with the rest of the world, when what we put in this release isn't the
driving force behind everyone else's apps. I think we should go with
this layout and continue to publicize -safe.
Craig
