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

> > The question, then, is do we reserve special ports for protocols that
> > sit over SSL, or do we try to negotiate up to SSL after connecting to
> > the normal port?  If we do the later, I get worried about security.
>
> Yea, there's more ways to shoot yourself in the foot when you're
> negotiating SSL/TLS inside another protocol. I think the
> problems are surmountable as long as the application can
> notify the user (or some decision-making code in the server)
> when attempted SSL/TLS negotiation fails.
>
> The biggest drawback to seperate assigned ports for the TLS
> versions of N services is the limited port number space below
> 1024. Is there any reason (other than convention) for using
> port numbers under 1024?  I know some filtering router
> "firewalls" will need to be re-programmed, but other than that
> small problem why not use ports over 1024?
>

There is another drawback. If many services are secured by TLS
and new ports assigned for each service, then what happens when
the next security-technology-of-the-day comes along?

Imagine if the services listed in this forum were secured by SSL
2.0, SSL 3.0, TLS, Kerberos 4, Kerberos 5, and each service
given its own port. What sense does that make?

Perhaps the community would be better served not by
registering a new port for every service but by developing a
framework for each service where multiple security
technologies can be supported. There is precedent: several
services support security negotiation (e.g., telnet, ftp,
and IMAP) and extensions are being proposed for others (e.g.,
NNTP).


-dpg

Received on Thursday, 6 February 1997 11:50:02 UTC