Subject: Re: Telnet Encryption Specification

From: Jeffrey Altman <[email-masked]>
Date: Tue, 3 Feb 98 18:20:20 EST

> Ted,
> 
> Things being what they are, you and I will probably need to get together. I've
> currently have a Telnet over TLS I-D in circulation (see
> draft-ietf-tn3270e-telnet-tls-00.txt).
> 
> The proposed TLS/SSL mechanism doesn't use the RFC1416 style because that (a)
> the TLS negotiation mechanism can't be shoehorned into the RFC1416-style (it
> happens strictly at the binary level), and (b) TLS is really
> encryption-then-optional-authentication but RFC1416 is really
> authentication-then-maybe-encryption.  To summarize, the two don't mesh all
> that well.
> 
> However, there's some overlap, particularly in the authentication area. I'd be
> interested to here your thoughts in this area.
> 
> /msb
> 

So what are you currently using for the Optional Authentication?

Are you using a Telnet Option?  If so, what value?  

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
       612 West 115th St #716 * New York, NY * 10025 * (212) 854-1344
    http://www.columbia.edu/kermit/k95.html * [email-masked]

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 4 Feb 98 1:29:44 EST

> "Theodore Y. Ts'o" <[email-masked]> writes:
> 
> >> The fix for this would be to use CBC(*), but that has the down side of
> >> being slower and requiring more bytes on the wire, since telnet is a
> >> character-at-a-time protocol, and CBC requiers that you block data into
> >> 8 byte chunks.  (The advantage of CFB and OFB is that they work well
> >> with streaming protocols.)
> 
> Just as a point of reference, I regularly use ssh (which has quite a
> bit of overhead) for interactive traffic over a modem, and I can't
> detect any difference in latency over a non-protected connection.  I
> think the days where we need to worry about the extra overhead are
> also over.
> 
> 		Marc
> 

However, file transfers over a Kerberos Telnet connection from a 
166 MHz Pentium to a rather fast Sparc system run at about 60% of the
speed of an unencrypted connection.  This is due entirely to the
overhead of the encryption.  So I don't think the cost are completely 
irrelevant.

---

From: William "Chops" Westfield <[email-masked]>
Date: Wed, 4 Feb 98 0:00:26 PST

The costs of encryption are especially relevant when "everyone" starts
doing it.  A couple of users using ssh might not significantly load a modern
CPU, but if everybody does it (100+ users?), your CPU might not be doing
much other than encryption.   Doubly so for poor terminal servers with
lighter weight processors expecting specialized IO hardware to give them
appropriate amounts of data transfer capability.

BillW
cisco

---

From: John Hawkinson <[email-masked]>
Date: Wed, 4 Feb 1998 07:20:13 -0500

| Just as a point of reference, I regularly use ssh (which has quite a
| bit of overhead) for interactive traffic over a modem, and I can't
| detect any difference in latency over a non-protected connection.  I
| think the days where we need to worry about the extra overhead are
| also over.

Another important consideration (the first being the CPU issues) is
behavior in the face of suboptimalities in network performance
(i.e. loss or excessive jitter). Yesterday I was fighting a nasty
battle against both and found ssh to be unusuable for interactive
work, even though telnet worked acceptably.

I'm not sure if the CPU commentary is meaningful in a CBC vs. OFB/CFB
discussion, versus an "encrypt vs. not encrypt" discussion.

--jhawk

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 5 Feb 98 13:52:47 EST

> > Anyway, reviving the Telnet Working Group I believe would be a good
> > idea.  There are other drafts in progress (3270Extended, ???) which 
> > could also be handled by that group.
> 
> Uh, that's my working group (TN3270E, that is). Extra credit for enthusiasm,
> though :-).
> 
> /msb
> 

So maybe your working group should be extended to handle Telnet in
general.

---

From: David Borman <[email-masked]>
Date: Thu, 5 Feb 1998 13:49:27 -0600 (CST)

Reactivating the Telnet WG would require
	1) Having someone volunteer to be the WG chair
	2) Updating the WG charter
	3) Approval of the updated charter by the IESG

I can't volunteer as the WG chair, because my attendance at
IETF meetings has been so spotty for the last several years,
though I will continue to administer the mailing list.

But I think that reactivating the Telnet WG would be a
good thing.

		-David Borman, [email-masked]