IETF Logo Mail Archive

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

Martin Rex <mrex@sap.com> Tue, 08 December 2009 13:47 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 A1ED03A69BB for <tls@core3.amsl.com>; Tue, 8 Dec 2009 05:47:55 -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 BNv9y60p-m8p for <tls@core3.amsl.com>; Tue, 8 Dec 2009 05:47:55 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A26333A683B for <tls@ietf.org>; Tue, 8 Dec 2009 05:47:54 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB8Dlg3f014626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 14:47:42 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912081347.nB8Dlf2g010663@fs4113.wdf.sap.corp>
To: Pasi.Eronen@nokia.com
Date: Tue, 08 Dec 2009 14:47:41 +0100
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31A4FCB4@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 8, 9 09:50:27 am
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] Last Call: draft-ietf-tls-renegotiation (Transport Layer
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: Tue, 08 Dec 2009 13:47:55 -0000

Pasi.Eronen@nokia.com wrote:
> 
> Martin Rex wrote:
> > Chris Newman wrote:
> > 
> > > 1. Running code: multiple implementations and interop testing was
> > >    performed on an earlier version of draft-ietf-tls-renegotiation.
> > 
> > Even EKR admitted that implementing the update is an insignificant
> > amount of work.
> 
> Martin: Do you agree with EKR here or not?
> 
> (I guess "the update" here means "any of the proposed variants").

Implementing original TLS extension RI draft and my current one is about
the same amount of work (but results in double the amount of code
for TLS extensions RI draft for implementations that _already_have_
TLS extensions support, much more for those that don't).

When MCSV is implemented and special cases are addressed, then
TLS extensions RI is a little more work.

The big difference comes with testing (which any reasonable QA can
not simply ignore).  The amount of testing required for TLS extension RI
is significantly higher than it is for my approach, simply because
all the code that I added is used all the time during regular
interop tests, there are hardly any special cases in mine.


-Martin

v2.23.0 | Report a Bug | By Email