Re: [TLS] draft-rescorla-tls-renegotiate.txt

Marsh Ray <marsh@extendedsubset.com> Fri, 06 November 2009 23:41 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 0A2933A6921 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 15:41:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 d080uskkZMXg for <tls@core3.amsl.com>; Fri, 6 Nov 2009 15:41:02 -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 38F5E3A68F9 for <tls@ietf.org>; Fri, 6 Nov 2009 15:41:02 -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 1N6YQn-000DZj-EE for tls@ietf.org; Fri, 06 Nov 2009 23:41:25 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 91150667B for <tls@ietf.org>; Fri, 6 Nov 2009 23:41:23 +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: U2FsdGVkX1/LcBh9/i5UdFRMerVDnNsVLAxrSEGYc9k=
Message-ID: <4AF4B423.2000309@extendedsubset.com>
Date: Fri, 06 Nov 2009 17:41:23 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
References: <200911061959.nA6JxnnB001831@fs4113.wdf.sap.corp> <4AF497C5.5060801@REDHAT.COM> <4AF4A091.3070609@pobox.com>
In-Reply-To: <4AF4A091.3070609@pobox.com>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] 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: Fri, 06 Nov 2009 23:41:03 -0000

Michael D'Errico wrote:
> 
> A server can still negotiate an SSLv3 connection as it does today.
> It just can't re-negotiate that connection later.

But on the server question:

There is a large, but unknown, group of sites that really depend on
being able to serve different requirements for client certs from the
same IP.

For example, one development tool widely used in the industry is MS
Visual Studio 2005. It provides a nice IDE for developing web apps
(among other things). It has wizards all over the place. One will
generate a "web service" project, another will make an installer for it.
This WS architecture frequently uses client cert authentication and IIS
provides features to map client certs to OS user accounts. There are
other client auth schemes in use, too, pretty much anything supported by
HTTP. Server certs are expensive (or require approval to obtain) so I
suspect it's very common to serve web service projects requiring client
cert auth from the same hostname and IP as a web site that does not.

Just making an argument for how important per-request renegotiation is
in some deployments.

My guess is that any patch introducing an (SSLv3 xor renegotiation)
requirement is likely to cause a bit of headache. Consider the
possibility that a developer has an app that he tests and works fine on
his machine. But once he installs his app on the production server, all
the sudden some mysterious subset of clients (those using SSLv3) will
stop being able to connect to some different service which shares the
same IP address. Trial-and-error troubleshooting causes puts the blame
on the developer.

We should consider the possibility that it could introduce more (and
more confusing) incompatibilities than just deprecating SSLv3 outright.

> This is true for
> all TLS versions as well; you can still allow unpatched clients to
> connect, just not renegotiate.

I strongly suspect it also applies to many SSLv3 clients.

- Marsh