Re: NEW DRAFT: Regularizing Port Numbers for SSL.

Dennis Glatting writes:
> 
> 
> > The whole point is that this is for everyone, not for the quick or
> > aggressive.  Drop the bully-boy behavior and toss the week or
> > two away until the positions are stated clearly.
> >
> 
> With that said...
> 
> It isn't clear (to me) the value to the community of registering
> all those ports and developing all that code except, perhaps,
> to the profit margins of the few. One of the most disturbing
> comments of one of the proponents is the one "I'm a short term
> pragmatist and a long term idealist". The implication is the
> few want to get their product to market, without considering
> alternatives or engineering good solutions, and those of us
> with long term Internet interest are stuck holding their bag.

I don't equate registering ports with engineering.
I'm a proponent of including TLS in each protocols negotiation rather
than running on seperate ports.  But there are very good reasons for
designating ports for TLS versions of services.

First off, for each protocol to use TLS, someone has to do the work
of integrating the TLS negotiation into the protocol.  That's not
all that much work but it's only the beginning, because having TLS
integrated into a protocol is only useful if there's a standard way
of doing it, so you can talk to other implementations.  That means
going through that protocol's standards comittie, or getting agreement
with the main developers, or both.  It's a slow process, and one that's
outside the scope of TLS.

Second, people want to use SSL/TLS to do things now.  It's not just
a laboratory protocol, there's a number of implementations that
have been around for a while, and people want to do things with it.
It's a lot more useful to have standard ports for those services
than the situation we have now, where various developers just pick
ports and use them, or get the IANA to register them without letting
the SSL/TLS community know.

Last, setting aside these ports does not mean that we're stuck using
them forever.  Like I said before, I think that negotiating SSL/TLS
inside application protocols is the way to go.  If I'm right, then
that's what will happen in the future as the people who develop applications
for those protocols realize that it's possible and a good idea.
If I'm wrong about that, well then there's no harm and we can go on
using the proposed/existing  *s SSL/TLS-enabled services.
If I'm right, then those ports will become unused... no big deal.


To answer some other people's questions, Ray Sarna asks "what about SSH?".
We discussed SSH at the second 'ad hoc' meeting (and Tatu Ylonnen was there)
that formed the working group.  We also discussed SSH in the mailing list.
You should check for an archive, a web search should bring up a couple.
The group's decided not to deal with SSH in _this document_.
I think it's a bad idea to re-hash old discussions, standards bodies
that do never get anywhere.   Speaking of which, the last time we discussed
assigning new ports vs. negotiating SSL/TLS inside application protocols
the concensus seemed to be to go with new ports... for the same reasons
people want to do so now.




-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

Received on Saturday, 8 February 1997 12:25:31 UTC