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

Martin Rex <mrex@sap.com> Fri, 11 December 2009 14:58 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 CC37328C0EE for <tls@core3.amsl.com>; Fri, 11 Dec 2009 06:58:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.193
X-Spam-Level:
X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 ewuQtutIdGWZ for <tls@core3.amsl.com>; Fri, 11 Dec 2009 06:58:42 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 8EA8D28C0E9 for <tls@ietf.org>; Fri, 11 Dec 2009 06:58:42 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBBEwQSq010616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 15:58:26 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912111458.nBBEwPFR008154@fs4113.wdf.sap.corp>
To: nelson@bolyard.me
Date: Fri, 11 Dec 2009 15:58:25 +0100
In-Reply-To: <4B21B79E.8060509@bolyard.me> from "Nelson B Bolyard" at Dec 10, 9 07:08:14 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 14:58:43 -0000

Nelson B Bolyard wrote:
> 
> > 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.
> 
> It's not "much more prominent".  It's merely HTML.  Prettier, perhaps.


Let's see:

The following URL says "SPEC":
http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM

This URL says "Draft":
http://web.archive.org/web/20050206122938/wp.netscape.com/eng/ssl3/draft302.txt

and includes an _explicit_ expiration of May 1997.


And concerning extensibility of SSLv3, here's a statement
from Tom Weinstein, listed in the Authors section of the
Nov 18th, 1996 draft as a Netscape employee from
10-Oct-1996:

http://www.imc.org/ietf-tls/mail-archive/msg00325.html

  The lack of a general extension mechanism in SSL v3 is a feature, not a
  bug.  This is a security protocol, and so susceptibility to analysis is
  a good thing.  Simplicity and rigidity are features here.  SSL does
  provide for forwards compatibility by allowing version negotiation and
  protection from version rollback attacks.

  -Tom Weinstein, Netscape, 10-Oct-1996, Co-Author of draft302.txt


So as far as Netscape's SSLv3 is concerned it didn't not contain
extensibility.  What is in that November draft is something the
TLS WG wanted for TLSv1.0.

Keep in mind that in mid of 1996, SSLv3 was not under development,
it was already widely deployed.


> 
> It amuses me that you tell me what Netscape did and didn't do with those
> pages, because *I* was the Netscape employee who maintained that section
> of the web site from 1998-2005, beginning when I implemented TLS 1.0
> in Netscape's NSS.

You could have removed the explicit expiration notice on draft302.txt
and you could have renamed it to "3.0 final SPEC", you could have
removed the version that you condered outdated--or at least clearly
marked it as outdated _in_the_document_ if that was what you or
Netscape intended it to be.


-Martin