NULL_ ciphersuite meets ftps

*** Resending note of 10/02/97 15:50

  I believe that the proposal to remove NWNN and the proposal
to define 990 as ftps are mutually exclusive.  This follows some
discussion I had at the FTP-EXT W/G in San Jose who had the following
comments about the FTP-SSL proposal.

- The data connection and the control connection in the FTP protocol
are completely separate.  Negotiating one level of security for the
control connection should not imply any behavioural changes to the
data connection.

- Saying that the data connection must be TLS if the control conection
is is only valid if ..
  i) the data connection is capable of setting its' own policies should
     it so wish.
 ii) The overhead for sending unprotected or pre-protected data is
     minimal. (and is possible).
  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)

   Thus, by removing the NWNN option in TLS, and without specifying
how the control connection can negotiate the behaviour of the data
connection (in fact specifying nothing about the data connection)
you are removing the ability of the ftp client/server to negotiate
unprotected data connections (for file lists/pre-encrypted data) this
is not flexible enough for all the uses of FTP and we should not
move forward with this as a specific way of solving a specific problem
and thus tying down a general protocol like FTP.

   I agree the NWNN is a good candidate for removal, in which case can
I please propose the following in the specific case of FTP.

   - do NOT propose 990 for ftps (or 989 for ftps-data)
   - instead, ask the IANA (or whoever) for the telnet string for TLS/SSL
      as discussed on page 5 of draft-ietf-cat-ftpsec-09.txt
   - point people who want to do FTP/TLS at the cat ftpsec draft instead
      of encouraging them to take liberties with ftp.  (That way the
      draft gets more encouragment to become an RFC) and use the AUTH
      and PROT commands to negotiate TLS at the application level.
   - write a document desribing the policy decisions that clients and
      servers should be aware of, the parts of draft-ietf-cat-ftpsec-09
      that need to be used for TLS, the expected behaviour of clients
      and servers when negotiating data channel protection etc...
      This is the direction that the draft-murray-ftp-auth-00.txt
      document is going now that the CAT one has re-emerged and I am
      sure that Tim and Eric (any myself) would welcome interested
      co-authors from those amongst you who are desparate to get an
      inter-operable secure FTP defined.

   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.

Thanks,






Paul

Received on Monday, 10 February 1997 12:01:47 UTC