IETF Logo Mail Archive

Re: [TLS] simplistic renego protection

Stefan Santesson <stefan@aaa-sec.com> Fri, 20 November 2009 06:49 UTC

Return-Path: <stefan@aaa-sec.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 7175C3A690B for <tls@core3.amsl.com>; Thu, 19 Nov 2009 22:49:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.822
X-Spam-Level:
X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 IBsZ7u7dfSya for <tls@core3.amsl.com>; Thu, 19 Nov 2009 22:49:37 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id AE3383A6909 for <tls@ietf.org>; Thu, 19 Nov 2009 22:49:37 -0800 (PST)
Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 1C2A429CD01 for <tls@ietf.org>; Fri, 20 Nov 2009 07:49:35 +0100 (CET)
Received: (qmail 30789 invoked from network); 20 Nov 2009 06:49:33 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <mike-list@pobox.com>; 20 Nov 2009 06:49:33 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 20 Nov 2009 07:49:29 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Michael D'Errico <mike-list@pobox.com>, tls@ietf.org
Message-ID: <C72BFA89.67A2%stefan@aaa-sec.com>
Thread-Topic: [TLS] simplistic renego protection
Thread-Index: AcpprZtYS8qsv/xZ8kOIlYMTVsFCUQ==
In-Reply-To: <4B061A0E.3000002@pobox.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [TLS] simplistic renego protection
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, 20 Nov 2009 06:49:38 -0000

I fully agree,

However, just because a server accepts renegotiation with an unpatched
client, does not necessarily mean that the service provided over TLS is
vulnerable.

One example is if authentication is performed with proper channel binding in
a layer above TLS and the service is provided under that security context.

I second that lenient server - unpatched client must work while ensuring
that lenient server - lenient client can't be abused using downgrade
attacks.

/Stefan


On 09-11-20 5:24 AM, "Michael D'Errico" <mike-list@pobox.com> wrote:

> Yes.
> 
> Some servers apparently cannot function without renegotiation.
> They will need to continue providing service to unpatched
> clients for some amount of time and thus remain vulnerable.

v2.23.0 | Report a Bug | By Email