I believe that this new draft addresses the concerns brought up on the SSL-Talk and IETF-TLS lists, yet still allows us to move forward for those who need to interoperate now. If you have any comments about these specific requests, please cc: both lists, <SSL-Talk@netscape.com> and <ietf-tls@w3.org>. However, any comments regarding requirements for single port/port mapping solutions should be exclusively on <ietf-tls@w3.org> as that will be in our queue for future standards work. I will be sending the final version of this request to the IANA on Wednesday, November 12th. --------- The SSL 3.0 protocol has the broadest implementation of any security standard to date, with both Netscape and Microsoft using it in their popular servers and browsers. SSL 3.0 has been submitted to the TLS working group of the IETF, and is is proceeding out of internet-draft status under a new name, TLS. Tim Dierks and I are editors for that working group, Win Treese <treese@OpenMarket.com> is the working group chair, and Jeff Schiller <jis@mit.edu> is the IESG area director over the WG. Tim are I have two documents undergoing revision: <draft-ietf-tls-protocol-00.txt> & <draft-ietf-tls-ssl-mods-00.txt>, which were approved during the last working group meeting in San Jose, and are being merged into one draft as we speak. One area that I am trying to resolve are the port and port naming issues with TLS/SSL. As a transport layer security standard, TLS/SSL can work transparently with existing application level protocols (such as http, nntp, nttp) without *any* change to the protocol other than using a different port number. As an example, the popular http protocol uses port 80, and the SSL enabled version of http uses 443. It is possible for a single port to be used for both unsecure and secure uses, however, this requires two things: * Changes in the application level protocols which must be separately adopted by each working group over such protocols. An example of changes that would allow for a single port in the FTP protocol is covered in <draft-murray-auth-ftp-ssl-00.txt> * Support by firewalls to understand and resolve use of a single port for both unsecure and secure uses. It is also possible that there could be a single port/port mapping solution to allow any protocol to be used with TLS without port proliferation, however, after considerable discussion in the TLS working group there is no easy design that resolves both architecture and security issues. We have agreed to add to the TLS agenda and charter to resolve this problem in the future. Thus, until each protocol is revised to allow for authenication under a single port, or a single port/port mapping solution is architected, we will require separate ports for TLS/SSL implementations of the most popular protocols. There are a number of ports currently registered with the IANA the for use by the SSL protocol. They are: https 443/tcp https ssmtp 465/tcp ssmtp snews 563/tcp snews ssl-ldap 636/tcp ssl-ldap spop3 995/tcp SSL based POP3 As the above registrations are inconsistant, and most don't even mention SSL or TLS, we would like to get these port assignments and names regularized in the listing as follows: https 443/tcp http protocol over TLS/SSL smtps 465/tcp smtp protocol over TLS/SSL (was ssmtp) nntps 563/tcp nntp protocol over TLS/SSL (was snntp) ldaps 636/tcp ldap protocol over TLS/SSL (was sldap) pop3s 995/tcp pop3 protocol over TLS/SSL (was spop3) There is also currently a desire among existing SSL implementors to register a number of additional ports mappings for other protocols such as ftp. We want to avoid port proliferation as much as possible until we have a long term solution, so we have limited these requests to those protocols in which we have recieved commitments from a minimum of 2 independent implementations by developers. We have been told that some of these invididual implementors may have attempted to register ports for these uses of SSL, but as of today they have not recieved registration for these assignments. We would like to suggest the following: ftps-data 889/tcp ftp protocol, data, over TLS/SSL ftps 990/tcp ftp protocol, control, over TLS/SSL imaps 991/tcp imap4 protocol over TLS/SSL telnets 992/tcp telnet protocol over TLS/SSL ircs 993/tcp irc protocol over TLS/SSL I also have a question -- who requested the following service? We don't know if it is our SSL or something else with the same acronym. naming-iiop-ssl 261/tcp IIOP Naming Service (SSL) Under your procedures, you ask for answers to the following questions: 1) What is the protocol between the user machine and the server machine? It is the TLS 1.0 or SSL 3.0 protocol as defined in <draft-ietf-tls-protocol-00.txt> & <draft-ietf-tls-ssl-mods-00.txt>. 2) What message formats, types, op codes, sequences are used? It is the TLS 1.0 or SSL 3.0 protocol as defined in <draft-ietf-tls-protocol-00.txt> & <draft-ietf-tls-ssl-mods-00.txt>. 3) What functions are performed by this protocol? Securing and authenticating the transport independently of the application protocol. 4) Is broadcast or multicast used? If so, how and what for? No -- TCP only is defined by TLS/SSL at this point, however, we'd like to at least hold the UDP ports in reserve for the future. 5) Do you want a well-known assigned system port in the range 0-1023, or a registered user port in the range 1024-65535 ? They need to be in a the well known range as they are largely being implemented initially by unix developers who want to be sure that it is the well-known range. 6) What short name (14 character maximum) do you want associated with this port number? ftps-data 889/tcp ftp protocol, data, over TLS/SSL ftps 990/tcp ftp protocol, control, over TLS/SSL imaps 991/tcp imap4 protocol over TLS/SSL telnets 992/tcp telnet protocol over TLS/SSL ircs 993/tcp irc protocol over TLS/SSL If there are any questions as to our authority to request such changes, these changes have been run by the WG Chair, Win Treese <treese@OpenMarket.com>and Jeff Schiller <jis@mit.edu> is the IESG area director over the TLS WG. In addition, these requests were run by Netscape, Microsoft, the SSL-Talk mailing list and the IETF-TLS working group mailing list, and rough consensus was achieved before being sent to you. If you have any questions, please feel free to give me a call at 510/559-1500 or email me at Christopher Allen <ChristopherA@consensus.com>. ------------------------------------------------------------------------ ..Christopher Allen Consensus Development Corporation.. ..<ChristopherA@consensus.com> 1563 Solano Avenue #355.. .. Berkeley, CA 94707-2116.. ..Home of "SSL Plus: o510/559-1500 f510/559-1505.. .. SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..Received on Friday, 7 February 1997 17:28:49 UTC
This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:00 UTC