RE: which to implement?

Phil:  

Well, at least this list is getting lively!  Let me try to address the 
points you made in both your recent posts.  

First:  I know for a fact that Netscape solicited comments on SSLv3 
pre-publication, as an Internet Draft, and moderated SSL-talk.  There 
were plenty of comments and many of these along with some of the work 
we did with PCT are reflected in SSLv3.  ( I point specifically to 
separation of MAC and encryption key lengths and a shorter, more 
efficient handshake message flow which showed up in SSL after PCT was 
published.)  But my real point is that what went in and what didn't was 
primarily a Netscape decision.   As Taher said earlier, you chose from 
the comments you received.  Understandable - SSL is your protocol and 
you've got code to write, after all.  

But now we're at a different stage in the standards-setting process. 
 We're talking about an Internet Standard, and comments/contributions 
should come from the whole Internet community.  Frankly, only a small 
subset really cares, but from what we've seen so far, there are more 
than a few who want to show up in person to work on what will become 
TLS.   We all seem to agree that SSLv3 is a good starting point, but 
the robust discussions on the TLS list point out the need for some 
modifications/improvements before we call it TLSv1.  

This kind of collaboration has got to be the best way to get a 
widely-endorsed (and implemented!) standard quickly.  That's the whole 
reason we're coming and why we're not building a bunker around PCT and 
just defending it.  Why should we all go to the trouble of submitting 
anything to the IETF on the standards track if it isn't better than 
what's already out there - and more important, we all get to choose 
what gets in it?   Interoperability and open change control says it 
all.  

You're also right that we cannot expect a one or two day meeting to 
resolve all of the complex issues raised on the TLS list.  But what we 
can do in this meeting  - and in subsequent discussions on this list - 
is to get more people thinking and commenting. The working group should 
take full ownership of the protocol, and this is a great time to start.

The meeting is at the Garden Court in Palo Alto on May 29th.  I hope 
you and Taher can be there.

Barbara Fox
Microsoft



----------
From:  Phil Karlton[SMTP:karlton@netscape.com]
Sent:  Thursday, May 09, 1996 2:37 PM
To:  Bennet Yee
Cc:  Tom Stephens; 'Rodney Thayer'; 'pcttalk@ftp.com'; 
'ietf-tls@w3.org'
Subject:  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.

Let me correct that assumption. Features are in SSL 3 that Netscape has
no plans to use. They are there because those that involved themselves
in the early design asked for them. (For instance, the anonymous
Diffie-Helman key exchange is in there to support protocols where MITM
attacks are not an issue.)

Public responses to the initial sketches for SSL 3 were coming in as
early as August, 1995.

Microsoft has had copies of the spec since at least November, 1995.
There was been no feedback from Microsoft (asking questions or making
suggestions) until a completely rewritten spec showed up the month 
after
final SSL 3.0 spec went out.

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

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

I apologize for using the wrong word at 1:00 am.

PK
--
Philip L. Karlton		karlton@netscape.com
Principal Curmudgeon		http://home.netscape.com/people/karlton
Netscape Communications

     They that can give up essential liberty to obtain a little
     temporary safety deserve neither liberty nor safety.
		- Benjamin Franklin

Received on Thursday, 9 May 1996 20:30:51 UTC