Openness, change control, future protocol revisions

In message <31926588.59E2@netscape.com>, Phil Karlton writes:
> > Certainly, we
> > need to decide how much attention we, as an IETF working group rather
> > than as workers for some particular company or as academics, should be
> > pay to the (cost of the) effort already spent.  If we pay too much
> > attention to it, then we might as well disband the working group and
> > just adopt SSLv2.  (Or 3.  Or PCTv1 or 2.  Pick your own poison.)
> 
> I disagree. The output of this working group will not be a protocol that
> gets picked once in 1996 and never changes. Even before the March draft
> was finished, consideration was being given as to what was needed for
> 3.1. (Support for attribute certificates was high on that list.) It
> would be good if this group was driving that process.
> 
> What I am arguing for is to take SSL 3.0 as a base and to grow it with
> the features that are needed. Dropping a 35 page counter-proposal onto
> the table containing changes ranging from UDP support to password
> authentication means that efforts will not be focused on the respective
> ideas.

Hi Phil,

Thank you for correcting my error regarding SSLv3's development
process.  As I had said in response to Taher, I must have missed the
initial call-for-participation messages.  (I don't subscribe to
cipherpunks and had heretofore avoided mailing lists.  Still don't
like 'em much. :)

Anyway, SSLv3 may very well be a reasonable base.  Perhaps the STLP
modifications were too extensive or too one-sided (i.e., due to
Microsoft's desires), but since STLP was actually based on the SSLv3
draft, it seems to me that we *are* growing SSLv3 -- the argument is
really over whether the STLP changes to SSLv3 are needed.  And we had
a healthy argument/discussion going for a while.

I am less sanguine than you about the impact of future changes in the
protocol.  When this WG publishes the TLS protocol, products will be
created based on it, and that is likely to become a large installed
base.  How many SSLv2 clients are out there still (older Mozillas or
others), even when your company kindly gives away Mozilla for free (at
least to us academics)?  And consider the installed base of servers,
which may or may not be free.  There is a significant cost to upgrade,
though maybe it's good for business :).  This is just for the Web --
TLS is supposed to be broadly applicable to transport level
applications, so presumably we'll also see TLS-based telnet, nntp,
smtp, etc, etc, broadening the installed base.

The issue of protocol revision is still important nonetheless, even if
we assume there is zero cost to the user to upgrade.  While we are not
dealing with APIs in this WG directly, recalling the
SSLref&SSLv2->SSLv3 transition, it behooves us to *at least* write
down what sort of revisions are being considered for the next rev (as
much as is feasible) so that the APIs may be designed to accommodate
these changes.  Myself, I'd prefer to see this WG (or a subsequent
one) specify some minimal core API (for Unix, Windows, and MacOS), so
that we wouldn't run into these problems in the future, or at least
run into them once for everybody rather than multiply in various
different ways for various vendors / freeware implementations.  If we
don't do this and we do a protocol revision, we'll have to tread on
ice to avoid breaking the various flavors of APIs lest one vendor
decries foul because a change impacts -their- API more than their
competitors.  And we'll see more politics.

After all, as I see the issue of change control, a lot of the politics
is about the impact of revisions on time-to-market.  (Certainly true
of HTML tags.)  It's unfortunate that as scientists / engineers that
we have to deal with these business issues, but we should face reality
squarely and deal with it as best we can.  And I think that by
thinking ahead about the need for added features, revisions, and
considering API design issues, we would best serve the industry by
avoiding future politics.

-bsy

--------
Bennet S. Yee		Phone: +1 619 534 4614	    Email: bsy@cs.ucsd.edu

Web:	http://www-cse.ucsd.edu/users/bsy/
USPS:	Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114

Received on Friday, 10 May 1996 01:45:38 UTC