[Prev][Next][Index][Thread]

RE: which to implement? (reprise)



Taher: 

Just to set the record straight and be done with this:  we (and from 
what we hear other ISV's) DID contact Netscape with serious concerns 
about SSL before we even thought about doing PCT -  and while you 
listened, fixes just didn't come fast enough.  Frankly, we never would 
have expended the resources needed to create a whole new protocol if we 
thought there was a viable alternative.  But that's history and let's 
not continue to rehash or worse, repeat it.  

Netscape's commitment to the IETF process and recognition that the IETF 
transport-layer protocol must go beyond SSL 3.0 is a very positive 
step.  Netscape brings a great deal of experience and talent to this 
process as does Microsoft and the dozens of other companies involved 
with TLS.  Now that more people are working on the problem within the 
IETF, moving quickly to improve the protocol, upgrade the installed 
base and close any security holes is an Internet community 
responsibility rather than the duty of a single company.  This has to 
be good news for Netscape with SSL. It certainly is for us with PCT.  

Microsoft will continue to aggressively support the development of a 
new protocol which improves upon the existing protocols and, to use 
your own words, "generate the best solutions that meet the 
functionality, security and efficiency...for the community...".  We've 
already made a public commitment to this by publishing a strawman based 
on SSLv3 incorporating what we thought was valuable from PCT - but 
there's some serious technical work left to be done and we want to move 
fast. 

Are you going to join us in Palo Alto on the 29th? We can duke out 
separation of algorithms in defining cipherspec - and whatever else 
comes up in the meeting - in person...Let's make it a goal to have some 
serious thinking and resolution of differences done by Montreal.  

Best,
Barbara



----------
From:  Taher Elgamal[SMTP:elgamal@netscape.com]
Sent:  Friday, May 10, 1996 9:05 AM
To:  Barb Fox
Cc:  Tom Stephens; 'Bennet Yee'; 'Phil Karlton'; 'Rodney Thayer'; 
'pcttalk@ftp.com'; 'ietf-tls@w3.org'
Subject:  Re: which to implement? 

Barbara;

Of course we did put in the comments that interested people seemed to 
agree 
on. However, when you receive conflicting comments from different 
groups of 
people, it is really hard to go one way or the other and somehow a 
decision 
needs to be made.

I hope that through our discussions in the next meeting and in the IETF 
that 
we can resolve those differences that are actually hard to accomodate 
together in a single spec. It is and was always our objective to 
generate the 
best solutions that meet the fucntionality, security and efficiency 
(perhaps 
in that order) for the community and we actually did take the 
initiative to 
go to the IETF to get to the point where we have an industry standard. 
However, as you know the better standards are the ones that have 
actually 
been implemented and used.

I am expecting that the IETF will actually produce a different protocol 
from 
the current SSLv3, and always committed to supporting the effort, 
however, we 
actually have quite a bit of experience in implementing SSL both 
ourselves 
and by helping others resolve spec ambiguities and we hope that the 
IETF 
group will take that into consideration. I actually wished that you had 

forwarded the PCT objectives and comments to us before coming out with 
PCT -- 
perhaps you would have been surprised with our reaction.

The one thing I still do not like is separation of algorithms in 
defining 
cipherspec. I hope we can come to some agreement.

Cheers,

Taher


Barb Fox wrote:
> 
> 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

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