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

Robert Goodwin wrote:
> 
> > Labeling this UNIX "hack" as a security feature is incredibly
> > irresponsible. It never was and it never will be. Anybody that relies on
> > it for protection is security hazzard waiting to be exploited.
> 
> Indeed; I never intended to imply that it should be relied upon. But that
> *is* the reason why the numbers < 1024 are different; there is no other
> reason. As someone has pointed out to me, given the nature of the services
> being discussed with their proof of identity by both parties there is
> absolutely no security-related reason why numbers >1024 should not be used.

This notion is normally regarded as a UNIX-ism (probably a BSD-ism), the
reality is that there are NO trusted semantic bindings on the ordinal
value of the port number.
 
> 
> However, since port numbers >1024 are available to any user on the system,
> does one not run the risk of finding the port already in use by a user?
> 

It makes it harder in that the 16-bit namespace does not have a
partition of "well known" values, but that partitioning is mostly a
convenience that is wasteful of a somewhat critical resource.

Since some port numbers have already been assigned for use by SSL (and
can logically be assumed by TLS) through official channels, I assume
that the values assigned were deemed available and appropriate. The fact
that they have ordinal values less that 1024 does not seem significant,
only that they are reserved and well known. I believe that is the
essence of Christopher Allen's proposal that started this little
tangential discussion.

However, ...

I do beleive that if one was designed new protocols at or above what
might be labeled as the session (layer-5 in the OSI scheme) that the
design should incorporate a mechanism for selecting security options.
That would eliminate the need for dual port assignments.

One could also carry it further and make the service protocol stack
structure available through a directory server, including the port
number assigned to an instance of the service. That would eliminate the
need for all well known ports except for the directory (secure and
insecure, of course :-)).

All such mechanisms take careful thought and planning. They imply
changes in the ways things work, and that's something the industry has
been resistant to accept. I do not think such mechanisms are appropriate
for the issues being addressed by the current TLS specification.

-- 
Alan O. Freier               Corporate Cynic
<freier@netscape.com>        (415) 937-3638 (work)

Received on Friday, 7 February 1997 13:15:42 UTC