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.
>

Cheap and easy solution without consideration of long term
impact, impact on those who deploy those technologies and
maintain them (i.e., corporate and Internet
infrastructures), or whether it is a good idea.


> 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.
>

Perhaps, but how is TLS different than Kerberos IV or V, NetSP,
SPX, SESAME, EKE, SKPI, or any other security-protocol-of-the-day?

I do not see SSL's ubiquity a reasonable argument not to think
things though, consider alternatives, or rush the process.


> 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.
>

Why operate outside those committees rather than cooperate
with them?

A good example of a WG that does cooperate with other committees
is CAT. What makes TLS so righteous?


> 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.
>

I hear that a lot, but I only hear it from vendors.


> 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.
>

Yes, actually we are stuck with them. There is a little
expressed term given consideration in this forum: legacy.
XNS-auth is a registered port, it's old, and in some areas still
in use, so I'm told. The point is the actions taken here have long
term impact. I urge responsibility.


> 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.
>

I mostly disagree. Rehashing old discussions has value,
though sometimes monotonous and worse: sleepers. Even the
ASN.1/non-ASN.1 discussions (which drive me mad) have value.
SSL is a good protocol. I am confident its designers rehashed
old issues, time and again. That's the way things work: solve
problems and try to insure you do not repeat past mistakes or
create new ones.


-dpg

Received on Saturday, 8 February 1997 13:47:07 UTC