Re: which to implement?

Bennet Yee wrote:
> 
> 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.
> 

You are dead wrong. SSL3 feature set was actually taken fromcomments 
that were sent to us by about 12 companies or so -- the ones that cared 
to give us comments that is. Please review your facts.


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

-- 
Taher Elgamal	    elgamal@netscape.com
Chief Scientist, Netscape Communications
(T) 415 937 2898, (F) 415 428 4054

Received on Thursday, 9 May 1996 14:22:12 UTC