At 17:35 23.11.99 -0500, Jeffrey Altman wrote:
> > Protocols that offer increased complexity but no gain in security or
> > efficiency over other standards-track efforts, but are in use today, are
> > IMHO excellent candidates for Informational publication.
> >
> > Not for the standards track.
>
>I think the point of this debate is whether or not there is added
>strength to the encryption. And so far the opinions have been
>divergent. If 3DES is a better PRNG than DES then it is stronger.
Indeed. Or rather: If draft-altman-telnet-enc-des3-[cfb,ofb] describes a
mechanism where the best known attack is (significantly)more difficult than
the best known attack on draft-tso-telnet-enc-des-[cfb,ofb], it should go
to Proposed Standard (and the shoe is on the other foot; the -des- ones
shouldn't go forward to Proposed, since DES-protected data is known to be
vulnerable to brute force attacks).
>As we point out in the Drafts, the telnet encryption stream mechanism
>is susceptible to attacks. We know that. We have addressed it in
>various ways. Unfortunately, the Telnet AUTH option implementations
>for Kerberos 4, Kerberos 5, and Secure Remote Password all rely on the
>Telnet Encryption option for privacy. I don't think it is appropriate
>to send Telnet Auth to Proposed Standard with its reliance on an
>option that is Informational. Hence, the desire for all of these
>drafts to go to Proposed Standard.
I'm not at the moment questioning whether draft-tso-telnet-encryption-04.txt
should go to Proposed; the question hasn't been raised.
I'm questioning the arguments for letting
draft-altman-telnet-enc-des3-cfb-01.txt and
draft-altman-telnet-enc-des3-ofb-01.txt should go to Proposed.
>The TN3270 WG is working on a Telnet over TLS draft which has seen
>several independent interoperable implementations for TN3270 and well
>as more traditional telnet. My hope is to integrate Telnet over TLS
>with Telnet AUTH so that Telnet AUTH may be used to provide mutual
>authentication via a TLS using an ADH cipher. The one problem I have
>run into is that the TLS Library vendors (other than OpenSSL) have
>been very resistent to exporting the contents of the Finished messages
>to the application so that they may be used in the Telnet Auth
>negotiation to provide mutual authentication of the TLS. Once this
>draft goes to Proposed Standard I would recommend that the Telnet
>Encryption option be moved to Historical. But until that happens we
>need it on the standards track.
>
>These drafts have been floating around the net for almost eight years
>with many implementations. Its time for them to move on.
If it is possible to satisfy RFC 2026 para 4.1.1:
A Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it. However, the IESG may
waive this requirement in order to allow a specification to advance
to the Proposed Standard state when it is considered to be useful and
necessary (and timely) even with known technical omissions.
Yes.
Harald
--
Harald Tveit Alvestrand, EDB Maxware, Norway
[EMAIL PROTECTED]
