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

Martin Rex <mrex@sap.com> Fri, 11 December 2009 23:08 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 5F9FE3A68F6 for <tls@core3.amsl.com>; Fri, 11 Dec 2009 15:08:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.194
X-Spam-Level:
X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 39mciLoEnSHT for <tls@core3.amsl.com>; Fri, 11 Dec 2009 15:07:59 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id D954F3A67F6 for <tls@ietf.org>; Fri, 11 Dec 2009 15:07:58 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBBN7fRL019969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Dec 2009 00:07:41 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912112307.nBBN7eH3007023@fs4113.wdf.sap.corp>
To: nelson@bolyard.me
Date: Sat, 12 Dec 2009 00:07:40 +0100
In-Reply-To: <4B22CA88.7030007@bolyard.me> from "Nelson B Bolyard" at Dec 11, 9 02:41:12 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
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 23:08:00 -0000

Nelson B Bolyard wrote:
> 
> > 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.
> 
> Yes, all the drafts expired, including the one that says "spec".

Nope.  The one calles SPEC does NOT have an expiration.

When I complained to the supplier of our OEM SSL implementation about
an interop problem with TLS (not extension, only { 0x03, 0x01 }) in
August 2000, then they told me that the behaviour was according to
the SSLv3 spec.

I asked them for their spec document, and it was the March document.
So I went to www.netscape.com and used their "Site Search", and the
only document it found was the pretty (short) version of the SSLv3 spec.

Then I saw the reference to a Nov 18th document in the TLSv1.0 spec
(but not the slightest hint where to find it), and thats when I
downloaded the ietf-tls discussion list archive and found the document
attached to a posting from Win Treese (that attachment seems to have
been stripped in the current archive, it was attached to this message.

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

And although Win wrote this:
"For a variety of reasons, it's important to have this draft for the record."

neither TLS WG nor Netscape did anything substantial to keep
this document on record.

When I found that draft, I sent it to our supplier, so they would
use it.  But I could not blame them for not being aware of a newer
document, because it was obviously a big mess and no one cared.


> 
> > 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
> 
> Tom and I shared a cubicle.  His brother Jeff sat in the next cubicle over.
> One of my first mistakes in working on NSS's SSL code was changing the code
> for handling received client hellos to require that the length of the
> message be exact, with no extra.  Tom caught this mistake in his review of
> my patch.

I do believe that.  If you look at the TLS mailing list archives,
Tom was flamed violently for making such a statement.  He sure hadn't
forgotten that.   But as you can see in the referenced message above,
Barb Fox (Microsft) clearly points out that _NONE_ of the installed
base of SSLv3 in Oct-1996 was extensible and neither was there
an SSLv3 spec available providing this extensibility.


> 
> > 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.
> 
> I consciously chose to make NO changes at all to any of those documents,
> lest anyone accuse Netscape of continuing to try to revise the SSL 3.0
> specification rather than (or in parallel with) adopting the TLS 1.0
> specification.


Regrettably you did _NOT_ remove the expiration tag from the draft302
and did _NOT_ take down the outdated draft either.

You should have put up the "Beware of the Leopard" sign on your
overview page to make the picture complete.

-Martin