IETF Logo Mail Archive

Re: [TLS] simplistic renego protection

Marsh Ray <marsh@extendedsubset.com> Thu, 19 November 2009 19:19 UTC

Return-Path: <marsh@extendedsubset.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 CD7493A6834 for <tls@core3.amsl.com>; Thu, 19 Nov 2009 11:19:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.354
X-Spam-Level:
X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 5Ka26N4zGwHh for <tls@core3.amsl.com>; Thu, 19 Nov 2009 11:19:47 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 6A9703A67AF for <tls@ietf.org>; Thu, 19 Nov 2009 11:19:47 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NBCXg-0003bo-QU for tls@ietf.org; Thu, 19 Nov 2009 19:19:44 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B1BC8667C for <tls@ietf.org>; Thu, 19 Nov 2009 19:19:42 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19J5IM98IA8b2Ccl8crOatAi9y2CYmNa8c=
Message-ID: <4B059A4E.2050703@extendedsubset.com>
Date: Thu, 19 Nov 2009 13:19:42 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "tls >> \"tls@ietf.org\"" <tls@ietf.org>
References: <200911182000.nAIK0Qkm013905@fs4113.wdf.sap.corp> <4B04A792.7040607@jacaranda.org> <B197003731D4874CA41DE7B446BBA3E829CD28F1@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <4B059716.6010309@jacaranda.org>
In-Reply-To: <4B059716.6010309@jacaranda.org>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="UTF-8"
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: Thu, 19 Nov 2009 19:19:52 -0000

David-Sarah Hopwood wrote:
>
> If lenient servers are allowed, then I think it will take *much* longer
> until the vulnerability is eliminated from most connections.

If lenient servers are not allowed, a server admin cannot patch his
server until all clients have patched. The world will have long given up
on renegotiation by then and just patched to disable it entirely.

If lenient servers are allowed, the servers can patch right away and
immediately begin protecting connections made with patched clients.

This group has to quit thinking it can dictate limits on functionality
in order to compel the consumers of the technology to do things your
way. The world isn't exactly leaping at the chance to upgrade to each
new TLS RFC you know. Trying to do that on a security fix is going to
leave a particularly bad taste in people's mouths.

- Marsh

v2.23.0 | Report a Bug | By Email