Re: TWO WEEK LAST CALL: Regularizing Port Numbers for SSL.

> From: Tim Hudson <tjh@mincom.com> (by way of Christopher Allen)
> 
>  	https       443/tcp            # http protocol over TLS/SSL
>  	smtps       465/tcp    ssmtp   # smtp protocol over TLS/SSL
>  	nntps       563/tcp    snntp   # nntp protocol over TLS/SSL
>  	ldaps       636/tcp    sldap   # ldap protocol over TLS/SSL
>  	pop3s       995/tcp    spop3   # pop3 protocol over TLS/SSL
>  	ftps	    990/tcp            # ftp protocol over TLS/SSL
>  	imaps       991/tcp    simap   # imap4 protocol over TLS/SSL
> 
>     You might also want to have snews as an alias to minimise impact
> and also strongly recommend that people using the old name format change
> their code to use the official name.
> 
>     I'd also think that you should ask for ports for the following at
> the same time:
> 
> 	logins      992/tcp            # login protocol over TLS/SSL
> 	shells      993/tcp            # shell protocol over TLS/SSL
> 	telnets     994/tcp            # telnet protocol over TLS/SSL
> 	gophers     995/tcp            # gopher protocol over TLS/SSL
> 	ircs        996/tcp            # irc protocol over TLS/SSL
> 	sockss     1081/tcp            # socks protocol over TLS/SSL
> 
>     If you want to forward this to the list for discussion then feel
> free to do so ... however I don't think discussion is required as most
> of these are already in use out there (not on those ports [i.e. non-official])
> 
> Tim.


This discussion was held some time ago, and it's apparently time to have
it again:


> Date: Thu, 16 May 1996 13:27:22 -0700
> To: ssl-talk@netscape.com
> From: timd@consensus.com (Tim Dierks)
> Subject: Re: Any assigned numbers for other secure apps?
> 
> At 8:06 AM 5/16/96, sameer@c2.org wrote:
> >At 9:57 AM 5/16/96, Mark Bauman wrote:
> >> I was wondering if anyone has assigned any ports for secure applications
> >> other than HTTPS?  I am wondering about FTPS, TELNETS, SMTPS, etc.  Does
> >> anyone have these?  I could not find them in the latest Assigned Numbers
> >> RFC #1700.
> >>
> >    The protocol used in SSLtelnet and SSLftp use the same port as
> >the standard telnet and ftp ports.
> 
> Actually, there is some discussion over whether it's appropriate to run SSL
> versions of protocols to the same port or not. Netscape's position appears
> to be that since there isn't any defined way to distinguish a client
> attempting to negotiate an SSL session from a client connecting without
> encryption, it may be difficult to create secure versions of arbitrary
> protocols. Clearly, with many protocols you can do this heuristically or by
> using protocol-specific features (for example, it's my understanding that
> at least one secure ftp implementation connects without security, then
> sends a command to tell the other end to begin using SSL over the channel),
> but it's difficult to do generally (for example, with Telnet, it would be
> difficult to be certain whether a client was SSL or not by examining the
> first few characters that come over the channel; you might be able to make
> a real good guess, but you might be wrong some small fraction of the time).
> 
> I find the following port assignments listed in appendix A of the SSL 3.0 spec:
> 
>   443 HTTP over SSL (https)
>   465 SMTP over SSL (ssmtp) [pending]
>   563 NNTP over SSL (snntp) [pending]
> 
> It's my understanding that ports for other protocols, such as POP, Telnet,
> etc., have been applied for and are underway.
> 
> I've got some concern about the explosion of reserved port numbers this may
> cause; for example, will we need a whole new set for TLS? (Hopefully not,
> if it's close enough to SSL 3.0 to use SSL 3's version negotiation system.)
> The alternative is specifying for individual protocols unique ways to
> distinguish them in such a fashion that secure and insecure transports can
> share TCP port numbers.
> 
>  - Tim
> 
> Tim Dierks  --  timd@consensus.com  --  www.consensus.com
> Head of Thing-u-ma-jig Engineering, Consensus Development


I too have more than some concern about the explosion of reserved
port numbers for SSL-this and TLS-that.

I think we have consensus that https on port 443 is a done deal,
and that mail and news may also fall into that category.

But before we petition the IANA to officially sanction TLS port
explosion, we should do some serious thinking, planning, and
engineering.

There are 3 alternatives, only two of which have been discussed so far:
  * dedicate (and reserve through IANA) a separate port for every
    protocol that might benefit from TLS protection
  * use the normal port for each protocol, and negotiate security options
    (including TLS) from the application using something like SASL
  * define a one-byte TCP option which would allow the negotiation of
    a security protocol (e.g. TLS) during the TCP handshake.

The "exploding ports" option is bad for obvious reasons.

The application-specific negotiation has the disadvantage of requiring
each application protocol be modified to understand the negotiation
mechanism.

Defining a TCP option would be, IMHO, the cleanest solution.  If a
particular network stack did not allow the setting and retrieving of
TCP options through the socket interface, the stack would have to be
modified to use this method.

It is not necessary to register well-known port numbers with IANA in
order to experiment with, say, SSL-ized gopher or IRC.  The port
numbers must just be agreed-to within the community of users, either
by pre-agreement or by explicit specification within a URL
(ircs://irc.mumble.com:996).  IANA registration should not be pursued
until there is consensus that "exploding ports" is the architectural
direction in which TLS should be going.

So my official response to the LAST CALL is that no additional ports
be registered for "xxx protocol over TLS/SSL" at this time.  I believe
that both application-layer (SASL-like) and transport-layer (TCP option)
negotiation of security protocols are architecturally more appropriate
for the Internet.

Received on Wednesday, 5 February 1997 09:34:07 UTC