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

Nelson B Bolyard <nelson@bolyard.me> Fri, 11 December 2009 23:18 UTC

Return-Path: <nelson@bolyard.me>
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 D57C33A68FB for <tls@core3.amsl.com>; Fri, 11 Dec 2009 15:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level:
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599]
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 IPAp+OQW8xDv for <tls@core3.amsl.com>; Fri, 11 Dec 2009 15:18:23 -0800 (PST)
Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id EECF23A68C7 for <tls@ietf.org>; Fri, 11 Dec 2009 15:18:22 -0800 (PST)
Received: (qmail 29382 invoked from network); 11 Dec 2009 23:18:10 -0000
Received: from unknown (24.5.142.42) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 11 Dec 2009 23:18:10 -0000
Message-ID: <4B22D333.1000202@bolyard.me>
Date: Fri, 11 Dec 2009 15:18:11 -0800
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: tls@ietf.org
References: <200912112307.nBBN7eH3007023@fs4113.wdf.sap.corp>
In-Reply-To: <200912112307.nBBN7eH3007023@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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
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:18:24 -0000

On 2009-12-11 15:07 PST, Martin Rex wrote:

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

They were mistaken about that, of course.  There never was ANY doubt or
controversy about how version negotiation was supposed to work.  Some
vendors just got it wrong.


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

Just call me "Pounce". :)