Re: [TLS] simplistic renego protection

David-Sarah Hopwood <david-sarah@jacaranda.org> Fri, 20 November 2009 18:41 UTC

Return-Path: <djhopwood@googlemail.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 AC1CB3A68D1 for <tls@core3.amsl.com>; Fri, 20 Nov 2009 10:41:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 aGvWeIgnVHd2 for <tls@core3.amsl.com>; Fri, 20 Nov 2009 10:41:37 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 5A1B93A6920 for <tls@ietf.org>; Fri, 20 Nov 2009 10:41:37 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 25so957265eya.51 for <tls@ietf.org>; Fri, 20 Nov 2009 10:41:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=9i0+mCD+LSL4+Df5NjAy5ArQ6urxZm6TAamavgB8RXk=; b=moOPK7xX6bLQxZdNWkmOew77GAZB9UppjqeP//b0RN3ao2msUFT4v4fXGw5ddHlkDI xugImQkwmfNgtHCHIpfwEHrS2zbq+a/MAfg4/jsU+AOPhCBfm/w8ov0KlEGFg2ovozbE +G6to6cqp+M9Jiep/kp9WfELlIVkbvps6aKLM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=T+wdP3hJaPCNXPHLdrWB3GfBaPapjOiqsT4E9Irz8lucnNpgBvsyGiE5Op8/Jz2Awc cMyPTeF8bH0rbSUxong+DOdnzJISy1wgDJ5UcLicBLBuUSRyz9eJd1kUENiuNoSEr90N kDeJIvrvmvR/Hw7TEYY5Yt1xfR7VaTalot9h8=
Received: by 10.213.96.6 with SMTP id f6mr1648169ebn.31.1258742491374; Fri, 20 Nov 2009 10:41:31 -0800 (PST)
Received: from ?192.168.0.2? (5e0212a1.bb.sky.com [94.2.18.161]) by mx.google.com with ESMTPS id 15sm418450ewy.8.2009.11.20.10.41.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Nov 2009 10:41:29 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4B06E2D7.2040302@jacaranda.org>
Date: Fri, 20 Nov 2009 18:41:27 +0000
From: David-Sarah Hopwood <david-sarah@jacaranda.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: tls@ietf.org
References: <C72BFA89.67A2%stefan@aaa-sec.com>
In-Reply-To: <C72BFA89.67A2%stefan@aaa-sec.com>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enig37F3DA455134A47E21984285"
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 18:41:48 -0000

Stefan Santesson wrote:
> On 09-11-20 5:24 AM, "Michael D'Errico" <mike-list@pobox.com> wrote:
> 
>> 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.
>
> 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'm skeptical. How can "proper channel binding" be done correctly in a
layer above TLS, if the TLS library merges renegotiated sessions?
Since the session merging will result in the client and server's state
at the higher layer(s) being out of sync, nothing can be assumed about
the correct functioning of those layers.

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

Obviously *if* lenient servers are supported, then we need to make sure
that lenient patched server - lenient patched client connections are
secure. But I remain unconvinced that lenient servers need to be supported.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com