Re: [TLS] Redefine Finished message for TLS 1.3 ?

Martin Rex <mrex@sap.com> Sun, 15 November 2009 03:22 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 0BF323A68AB for <tls@core3.amsl.com>; Sat, 14 Nov 2009 19:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.179
X-Spam-Level:
X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 oMMc0yIdNQqq for <tls@core3.amsl.com>; Sat, 14 Nov 2009 19:22:03 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E9C0B3A68AE for <tls@ietf.org>; Sat, 14 Nov 2009 19:22:02 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAF3MU9W008018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 04:22:30 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911150322.nAF3MTLA023042@fs4113.wdf.sap.corp>
To: Nicolas.Williams@sun.com
Date: Sun, 15 Nov 2009 04:22:29 +0100
In-Reply-To: <20091115015357.GP1105@Sun.COM> from "Nicolas Williams" at Nov 14, 9 07:53:57 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] Redefine Finished message for TLS 1.3 ?
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: Sun, 15 Nov 2009 03:22:04 -0000

Nicolas Williams wrote:
> 
> I think the consensus is probably to go with EKR's fix as is.  Note that
> my proposed fix could actually also be deployed for SSLv3 systems, IF it
> makes sense that they could get patched more easily than upgraded (which
> I doubt, but then, I've no data to go on).

There simply may not be an upgrade available.


The OEM SSL implementation that we have been shipped to our customers
for the last 8 years is SSLv3 only.

The next library that we are going to ship, and which I am currently
validating, contains TLSv1.0 (still no extensions).  We ordered
this "upgrade" 1.5 years ago in order to be able to use GOST ciphersuites
for customers in Russia.  The library will provide a plugin interface
for the GOST TLS ciphersuite(s), that plugin must be from a local
provider and certified by authorized agencies.

Switching to a different provider for the SSL implementation is not an
option for us.  The API architecture and credentials management is
"proprietary" / specific to this software.

One of our advantages is, that we have 100% backwards compatibility
for all the improvements during the last 8 years and for the future,
i.e. all of our customers get and use the same library (single codebase)
independent of the Release of our application that they're using.

The shared library/DLL is therefore compiled and tested on >40 different
Platform variants (2-3 OS Releases per vendor, 32- and 64-bit). 
(that is part of my work).

I know pretty well how much effort it is to upgrade a codebase from
SSLv3 only to SSLv3+TLSv1.0, because I've been doing review and
validation of those changes, changes in our app to allow configuration
of the new features, interop testing, etc.

Besides SSLv3, that library contains PKI-stuff, X.509 cert handling,
GSS-API (SPKM-like), PKCS#7, PK credentials and trust anchor management,
the crypto stuff for WS-Security.


Our app does have programmatic clients that use SSL to access
third party web-servers.  The app doesn't have an re-connect fallback
(what for -- since we have been supporting only SSLv3 all the time).


-Martin