Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

Martin Rex <mrex@sap.com> Fri, 11 December 2009 02:55 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A61B3A6909 for <tls@core3.amsl.com>; Thu, 10 Dec 2009 18:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.192
X-Spam-Level:
X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3hhEI-Mq7j0 for <tls@core3.amsl.com>; Thu, 10 Dec 2009 18:55:31 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id DAD983A6862 for <tls@ietf.org>; Thu, 10 Dec 2009 18:55:30 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBB2tFin027139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 03:55:15 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912110255.nBB2tE1V027686@fs4113.wdf.sap.corp>
To: nelson@bolyard.me
Date: Fri, 11 Dec 2009 03:55:14 +0100
In-Reply-To: <4B21B0E8.1080702@bolyard.me> from "Nelson B Bolyard" at Dec 10, 9 06:39:36 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2009 02:55:32 -0000

Nelson B Bolyard wrote:
> 
> >>> That is interesting information. Would you happen to have a copy of the
> >>> last "official" spec you can send me?
> >> Netscape's official SSLv3 spec as of 2005:
> >> http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM
> > 
> > That's pretty clear, SSLv3 did not have a provision for extending Client
> > Hello.
> > 
> >> As obvious from it's name that spec is a product of the TLS WG and
> >> the TLS WG decided to completely abandon (instead of publishing as
> >> informational RFC) that document so that it expired and vanished
> >> from the I-D repository 6 month later.
> > 
> > Seems like SSLv3 was simultaneously one of the most critical protocols
> > for net security and orphaned.
> 
> Stop right there.  Don't be led down the garden path.
> 
> Look at the parent page.  Look at
> http://web.archive.org/web/20050205162914/wp.netscape.com/eng/ssl3/


As I previously explained, I went to the Netscape WebServer in 2000
(when we acquired our OEM SSL implementation and I got the job to
make it accessible to our application), and the Netscape site search
sent me straight to the "pretty" SSLv3 spec (HTML and Postscript).

When I found a reference to a SSLv3 spec from November a few
weeks later, google did NOT find the 302 document.

So I searched through the archives of the IETF TLS mailing list,
where I finally found the document, because it had been posted
there in full.


The IETF internet-drafts repository in 1995-1998 kept only the
most recent version of a draft (deleted all previous documents),
and deleted an I-D when it expired.  The possibility to access
old internet draft versions through tools.ietf.org is something
I learned a few weeks ago.


Keeping an old version of a specification around in a MUCH
MORE promentiently fashion for 9 years tells a lot about what
Netscape thought of the draft-302.txt document.

After all, Netscape originally would have loved the IETF to
rubber stamp the original SSLv3 spec -- just that the IETF TLS WG
didn't like the rubber stamping idea in 1995/1996 -- and instead
insisted on defining a protocol named TLS backwards interoperable
with SSLv3.

So the draft302.txt document represents the start of TLSv1.0,
and not the final spec of SSLv3.


-Martin