Re: [TLS] simplistic renego protection

Stefan Santesson <stefan@aaa-sec.com> Sat, 21 November 2009 20:47 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 D9DFC3A6885 for <tls@core3.amsl.com>; Sat, 21 Nov 2009 12:47:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level:
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.301, 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 3j8n8HzKZU9x for <tls@core3.amsl.com>; Sat, 21 Nov 2009 12:47:50 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id E63F73A6812 for <tls@ietf.org>; Sat, 21 Nov 2009 12:47:49 -0800 (PST)
Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E630B28A216 for <tls@ietf.org>; Sat, 21 Nov 2009 21:47:07 +0100 (CET)
Received: (qmail 61984 invoked from network); 21 Nov 2009 20:47:00 -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 s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <david-sarah@jacaranda.org>; 21 Nov 2009 20:47:00 -0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Sat, 21 Nov 2009 21:46:58 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: David-Sarah Hopwood <david-sarah@jacaranda.org>, tls@ietf.org
Message-ID: <C72E1052.6851%stefan@aaa-sec.com>
Thread-Topic: [TLS] simplistic renego protection
Thread-Index: Acpq68R/IhbsQRhlgUGW2NBK5v784Q==
In-Reply-To: <4B0838E4.6010003@jacaranda.org>
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: Sat, 21 Nov 2009 20:47:50 -0000

On 09-11-21 8:00 PM, "David-Sarah Hopwood" <david-sarah@jacaranda.org>
wrote:

> 
> That's an oversimplification.
> 
> The attacker is able to add a prefix to the server's view of the session.
> This changes the server's state from what it would have been on an
> initial connection. How far the attacker's influence on the server's
> state extends into that session, is dependent on the application protocol.

So we are saying the same thing.

As you say, it depends on the application. What I claim is that it is
possible to design an application that use channel binding to keep itself
safe from this attack. All it needs to do is to make sure that it's state is
reset after completed channel binding.

The fact that it is possible to be safe despite this vulnerability is an
argument that lenient servers should be supported in the solution.

If I analyze my application and determine that it is safe from the attack,
then I could just allow gradual upgrades and stay lenient.

Or do you mean that it is impossible to design an application to be safe?

/Stefan