W3C home > Mailing lists > Public > ietf-tls@w3.org > January to March 1997

Re: NULL_ ciphersuite meets ftps

From: David Brownell - JavaSoft <David.Brownell@Eng.Sun.COM>
Date: Mon, 10 Feb 1997 10:51:46 -0800
Message-Id: <199702101851.KAA24117@argon.eng.sun.com>
To: ietf-tls@w3.org, pfh@uk.ibm.com
>   I believe that the proposal to remove NWNN and the proposal
> to define 990 as ftps are mutually exclusive.

I'd think not.  TLS_NULL_WITH_NULL_NULL is an unprotected connection.
Rather than using TLS with that cipher suite, just don't use TLS. 
No loss of functionality whatsoever.

>   The much preferred route is to allow the control connection to
> negotiate the protection level of the data connection.  (see the PROT
> command in the CAT draft-ietf-cat-ftpsec-09.txt)

This proposal is _far_ more complicated than the FTP approach described
in draft-murray-auth-ftp-ssl-00.txt ... and it doesn't even talk about
how to make this work with TLS.

Other than the PROT command (which could be added to the ftp-ssl draft),
the primary technical advantage that I notice in cat-ftpsec is that it
explicitly addresses Kerberos.  Wouldn't it be a lot better to follow
draft-ietf-tls-kerb-cipher-suites-00.txt to Kerberize SSL, and then
follow the ftp-ssl draft's simpler approach for the rest?

>    I don't see how this can be accused of holding anything up, as the
> draft (cat-ftpsec) is already written and awaiting eager developers.

Similarly, draft-murray-auth-ftp-ssl-00.txt is already written etc.

Speaking as a potential implementor, the approach in the ftp-ssl draft
gets my vote on time to market and on how readily it can be implemented
correctly and interoperably.

- Dave
Received on Monday, 10 February 1997 13:50:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:12 UTC