W3C home > Mailing lists > Public > ietf-tls@w3.org > January to March 1997

Re: NEW DRAFT: Regularizing Port Numbers for SSL.

From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
Date: Sat, 8 Feb 97 10:46:41 -0800
Message-Id: <199702081846.KAA11071@imo.plaintalk.bellevue.wa.us>
To: Eric Murray <ericm@lne.com>
cc: lpuadm@leonardo.net, ChristopherA@consensus.com, timd@consensus.com, patr@xcert.com, ssl-talk@netscape.com, ietf-tls@w3.org, treese@OpenMarket.com, jis@mit.edu

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:12 UTC