Re: [TLS] Simple way to drop re-negotiation in HTTP (Re: draft-rescorla-tls-renegotiate.txt)

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 09 November 2009 18:14 UTC

Return-Path: <Nicolas.Williams@sun.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 640613A6858 for <tls@core3.amsl.com>; Mon, 9 Nov 2009 10:14:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.017
X-Spam-Level:
X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 WMPxeDmIgQ+Q for <tls@core3.amsl.com>; Mon, 9 Nov 2009 10:14:10 -0800 (PST)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 7F1FB3A6814 for <tls@ietf.org>; Mon, 9 Nov 2009 10:14:10 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA9IEbmc018718 for <tls@ietf.org>; Mon, 9 Nov 2009 18:14:37 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA9IEagg031746 for <tls@ietf.org>; Mon, 9 Nov 2009 11:14:36 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA9HtZMN011737; Mon, 9 Nov 2009 11:55:35 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9HtZtB011736; Mon, 9 Nov 2009 11:55:35 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 09 Nov 2009 11:55:35 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Marsh Ray <marsh@extendedsubset.com>
Message-ID: <20091109175534.GB1105@Sun.COM>
References: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> <4AF497C5.5060801@REDHAT.COM> <4AF4A091.3070609@pobox.com> <4AF4B423.2000309@extendedsubset.com> <20091106234757.GN1105@Sun.COM> <4AF50CFD.7070705@extendedsubset.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4AF50CFD.7070705@extendedsubset.com>
User-Agent: Mutt/1.5.7i
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Simple way to drop re-negotiation in HTTP (Re: draft-rescorla-tls-renegotiate.txt)
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: Mon, 09 Nov 2009 18:14:11 -0000

On Sat, Nov 07, 2009 at 12:00:29AM -0600, Marsh Ray wrote:
> Nicolas Williams wrote:
> > The simplest way to drop re-negotiation in web servers is this (based on
> > an idea by Nelson Bolyard):
> 
> Wow that does make it sound easy. All we need to do for HTTPS is get a
> new port number assigned and the entire burden of the solution passes
> from the TLS specs to server implementors and site admins?

[Complaints that new port numbers for this are not really feasible
elided.]

For services inside a firewall this would be simple enough.  For all
others one may split the public vs. for-authenticated-users services
across multiple IP addresses rather than port numbers; this is [much?]
harder to automate.

But you convince me that this is not realistic.  To properly automate
this would require... software updates, which is pretty much what we
need to fix the bug in the first place; if this workaround is not
automated, then it won't be deployed.  Must likely, as you say, the
world will sit in the vulnerable state for a long time.  Very
unfortunate, that.

Nico
--