W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

Re: which to implement?

From: Bennet Yee <bsy@cs.ucsd.edu>
Date: Thu, 09 May 1996 10:44:16 -0700
Message-Id: <199605091744.KAA18131@work.ucsd.edu>
To: Phil Karlton <karlton@netscape.com>
Cc: Tom Stephens <tomste@microsoft.com>, "'Rodney Thayer'" <rodney@sabletech.com>, "'pcttalk@ftp.com'" <pcttalk@ftp.com>, "'ietf-tls@w3.org'" <ietf-tls@w3.org>

In message <3191A44E.167E@netscape.com>, Phil Karlton writes:
> In what way is SSL 3 not open?

AFAIK, the feature set was determined almost solely by Netscape.  If
we look at other standards in IETF/IEEE/ANSI/etc, we see a mix of both
adapt-a-de-facto-standard and standards making by a committee.  I
don't claim that standards making by committee is necessarily a good
thing, but I would say that adapt-a-de-facto-standard is not a
particularly "open" process.  While perhaps many programmer /
cryptographer hours have already been spent on SSLv3, it is not
"entrenched" like SSLv2.

Anyways, these are more of the business side of things than technical,
and I am a little leary about having to deal with it.  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.)

> The Microsoft strawman draft of STLP has not had that kind of analysis.
> The amount of work to come to the same degree of confidence in a
> protocol or implementation grows exponentially as the design gets more
> complicated. It's a sad fact that while adding feature A or feature B to
> an existing design, no compromise in the security of the system will
> result, but adding both can open an overlooked covert channel.

Ah, technical claims.

Please be careful about your terminology.  A "covert channel" has a
very specific meaning to people working in security, and I don't think
that meaning is what you intended.  Certainly as I had discussed
earlier regarding the privacy issue that D. Wagner had pointed out,
*all* of the protocols leak enough information for an eavesdropper to
subsequently probe a web site and determine what object the user was

There's probably enough muddling of minds out there already.

Regarding the exponential growth of complexity.  While cryptographic
protocol composability is still an active area of research, the
functionality changes in STLP are not exactly complicated.  Certainly
in systems design (and also possible to a certain extent in
cryptographic protocol design) we layer components to reduce the
design complexity -- when I hack code I certainly try to modularize
things, and much of the same techniques apply to protocol design (esp
the non-cryptographic components, such as record fragmentation or
compression).  To claim an exponential increase is wrong -- you've
even had some experience in modularizing a protocol's design.


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 Thursday, 9 May 1996 13:44:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:58 UTC