Re: NULL_ ciphersuite meets ftps

*** Resending note of 10/02/97 19:35

>>   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 loss is the ability of the Client/Server to exchange insensitive
data/pre-protected data without having a data security negotiation
conversation on the control connection (which the 'define an ftps port'
approach precludes.)

>>   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.

Agreed - but this is why it must be a 2 prong attack.
a) - state that the CAT W/G is the way to neogotaite FTP/TLS
b) - discuss exactly what the expected behaviours of the Client/Server
    need to be for TLS.  (when negotiating security). e.g. PROT C
    means no TLS at all (if NWNN is removed this is the only way of
    having a 'clear' connection); PROT P means negotiate TLS with
    whatever Ciphersuites are configured; PROT S and PROT E are
    replied to with a 536.  (This is just a suggestion - please don't
    flame the specifics here/yet !!!)

>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?

Maybe - but then you lose the availability of an implementable proposal
that can be done now.


>>    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.

This document needs (pretty much) completely re-writing since the
re-appearance of the CAT doc;  I was just in the process of updating
it and circulating it to the co-authors when all this blew up.  What I
am really looking for is a statement that this is worth pushing on with
and we won't get shot in the foot by people implementing ftps quickly
with interoperability problems that will get out of hand.

   Please note - the draft-murray-auth-ftp-ssl-00.txt does allow for






a separate port approach (allowing the data connection security to
be done at the TLS layer rather than on the control connection).  With
the removal of NULL_WITH_NULL_NULL, I believe that will need to be
revised, as it will not be acceptable to the FTP community.  (The only
way I can think of getting round it is to say that a connection
received on the TLS port does an implicit AUTH TLS, PBSZ 0, PROT P
in the server, thus allowing for a decent default and a future
negotation ability).  We also need to talk to the CAT group to discuss
the PBSZ command to see if we can specify a 'streaming' secure connection
(like TLS) with a value (say 0), or the ftp/tls draft will just say
that PBSZ, while required, is ignored (yuck).

Thanks,
Paul.

Received on Tuesday, 11 February 1997 05:10:40 UTC