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

> From tomw@netscape.com Wed Feb  5 14:02:26 1997
> 
> 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.

I guess I'm not being clear enough.  That is *not* the question.

Start with a security policy for, say, FTP.  That policy says either "I
will talk normal FTP" or "I will talk FTP over SSL".  The policy NEVER
says "I will talk normal FTP and then maybe switch to SSL" - that is a
meaningless concept.

The issue of port registration is do you use well-known port numbers
to communicate information about your security policy to the peer at
the other end of the connection.

If you use the port registration process, the peer knows that if he
gets (initiates or receives) a successful connection on port 21, then
your policy is to allow normal FTP.  If he gets a successful connection
on port xyz, then your policy is to do FTP over SSL. If he tries to do
an SSL connection on port 21, he waits for a timeout.  Tough cookies,
he shouldn't have done that.

If, on the other hand, all FTP connections are on port 21 and
negotiation is done using, say, a hypothetical transport layer TCP
security option, then your security policy doesn't change - either you
require SSL or you don't.  If you have two different policies, then use
two different servers, each on port 21.  When the peer connects, the
security option mechanism allows him to know what your policy is and
to establish a connection if his policy is compatible with yours.

I agree that application-layer negotiation is really ugly, because then
the application, not the protocol stack, is responsible for ensuring
that no user data flows until a connection compatible with the security
policy is established. It involves doing the negotiation on a clear
connection and then establishing a separate secure connection on the
same or a different port. That's why I think a TCP security option
is much cleaner architecturally than application-layer negotiation,
and is also more efficient (one less TCP connection to establish).

But negotiation does not allow either party to change the policy of the
other, so registration vs. negotiation is merely a question of how to
best facilitate interoperability.  I prefer negotiation to port
explosion.

Received on Wednesday, 5 February 1997 16:26:46 UTC