My mistake, Ken, I misread what you typed. I would consider SSH to be a
"fixed" version of telnet (as well as extended), SCP could be a "fixed"
version of FTP/RCP, and IPSec could be considered a "fixed" version of
IP. Besides, why fix old protocols? If something new is developed that
addresses and fixes problems of an older protocol, then go ahead and use
it. I don't really see the advantage to fixing something when there are
already suitable alternatives. Also, as I pointed out, some of the older
protocols still have a use out there, and to fix them would likely break
their current functionality. If you fixed all of the problems with FTP,
then anonymous, un-authenticated access to public sites would cease to
exist. 

Just my not-so-humble rantings,
Kenny

Ken D'Ambrosio wrote:
> 
> I did not state nor imply that VPN was a "protocol" -- it's an acronym for
> a suite of protocols that allow encryption of the data, as you full well
> know.  My point, however, is that it's still acting as a transport for
> insecure protocols -- instead of having to set up VPNs or SSH, dammit,
> FIX THE PROTOCOLS.  If the protocols were fixed right, then you wouldn't
> *NEED* SSH or VPN, and the inherent headaches, infrastructure, etc. that
> comes with it.  Furthermore, as long as you have crutches, it's just going
> to prevent a true "fixing" of the protocls at hand (again, IPv4-cum-NAT
> vs. IPv6 comes to mind).  As an example, come to think of it, SSH could,
> in this context, be considered a "fixed" form of the telnet protocol.
> 
> $.02.
> 
> -Ken
> 
> On Thu, 1 Mar 2001, Kenneth E. Lussier wrote:
> 
> > Let's digress.... "Neither SSH nor VPN"? I wasn't aware that there was a
> > "VPN" protocol. If there is, please correct me and sent an RFC reference
> > and I will be more than happy to look at it as well as admit my
> > ignorance. If not, and you mean Virtual Private Network in a generic
> > sense, then you would need to be more specific. IPSec has the ability to
> > create an end-to-end encrypted tunnel using session keys, *AND* encrypt
> > the individual packets that are sent through that tunnel. I will grant
> > you that many people utilize "tunnel-mode" which does exactly what you
> > say, tunneling insecure protocols through a secure tunnel. However, when
> > you tunnel an insecure protocol inside of a constant stream of garbage
> > data that is encrypted using 2048 (or 4096)-bit keys, you would have to
> > first penetrate the stream. By the time you do that, the session key has
> > changed, and you have to start over again. I would say that IPSEC is the
> > most secure (and probably the most complex) protocol out there, and
> > there are several sub-protocols that make it up (ESP, AH, SHA, etc.).
> > Now, if you are talking about PPTP, or an SSH-based VPN, then I would
> > agree.
> >
> > Kenny
> >
> > Ken D'Ambrosio wrote:
> > > P.S.  I happen to disagree with the thread against FTP -- specifically, it
> > > *is* plaintext, but all that SSH is really doing is allowing other things
> > > (eg. X sessions) to go in unencrypted form through an encrypted channel.
> > > It would be better, IMHO, if folks would start "embracing and extending"
> > > protocols such as FTP, and adding encryption to their functionality,
> > > instead of just bashing 'em.  Neither SSH nor VPN "fixes" any of the
> > > protocols that travel over them, they just mask the inherent underlying
> > > insecurity of said protocols.  Furthermore, since such protocols are
> > > already in place and quite entrenched, it'll be a whole hell of a lot
> > > harder to get folks to go with entirely new protocols (just ask when IPv6
> > > will be rolled out...), when the current ones should, IMHO, be updated,
> > > not thrown away.
> >

**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************

Reply via email to