Re: [TLS] simplistic renego protection

Martin Rex <mrex@sap.com> Tue, 17 November 2009 00: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 E22093A6A47 for <tls@core3.amsl.com>; Mon, 16 Nov 2009 16:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.962
X-Spam-Level:
X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.287, 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 9U5-ImVCTOlN for <tls@core3.amsl.com>; Mon, 16 Nov 2009 16:08:40 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id EE9A93A6811 for <tls@ietf.org>; Mon, 16 Nov 2009 16:08:39 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAH08bjF025351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Nov 2009 01:08:37 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911170008.nAH08bNp008572@fs4113.wdf.sap.corp>
To: david-sarah@jacaranda.org
Date: Tue, 17 Nov 2009 01:08:37 +0100
In-Reply-To: <4B01E547.4080704@jacaranda.org> from "David-Sarah Hopwood" at Nov 16, 9 11:50:31 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] simplistic renego protection
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, 17 Nov 2009 00:08:41 -0000

David-Sarah Hopwood wrote:
>
> I agree completely; the implementation effort for approaches
> using extensions is not significantly greater than for any other
> signalling mechanism. For the subset of implementations that
> already support extensions, it is less.

Looking at the code for TLS extensions in openssl-0.9.8g
your statement seems wrong.  It's more.

And if a codebase doesn't have extensions yet, it is significantly
more, because extensions is a generic container and there may
be more than one.

The latter is also a reason why interop testing becomes a magnitude
more complex, because you need to interop-test a huger number of
possible combinations.  Not necessarily for existing extensions code,
but definitely for extensions code that needs to be implemented first
time just for this fix.


It is extremely unwise to ask especially the maintainers of _old_ code,
who are most likely not even vulnerable (lacking server-side renegotiation
entirely), to add generic TLS extensions code and build themselves a
test client that can simulate all the various combinations possible
with TLS extensions in order to test they're processing it correctly.


-Martin