Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail

Bill Frantz <> Thu, 28 January 2010 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 337333A68DF for <>; Thu, 28 Jan 2010 13:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HYVDoGdVyNnD for <>; Thu, 28 Jan 2010 13:28:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3DF8E3A67FC for <>; Thu, 28 Jan 2010 13:28:56 -0800 (PST)
Received: from [] (helo=[]) by with esmtpa (Exim 4.67) (envelope-from <>) id 1NabvQ-0007Cw-1H; Thu, 28 Jan 2010 16:29:16 -0500
Date: Thu, 28 Jan 2010 13:31:46 -0800
From: Bill Frantz <>
X-Priority: 3
In-Reply-To: <p06240878c787913aa5c7@[]>
Message-ID: <r02010500-1049-89BFB88A0C5411DF826D0030658F0F64@[]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.1.5 (Blindsider)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7968325342742fc7c6f5400a8c6d76ad8e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Cc: Paul Hoffman <>
Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Jan 2010 21:28:58 -0000 (Paul Hoffman) on Thursday, January 28, 2010 wrote:

>The metadiscussion is raging (in both senses of the word), but the number of people expressing an opinion has dropped to near zero. 
>This is just a gentle nudge to those who care but have not responded to do so.

Let me cast a weak vote for:

   (1) I prefer publishing the specification as-is.

My real interest is getting on to the next version of TLS. I hope it
includes changes designed to:

(1) Limit the effect of bugs in a particular feature to those who actually
use the feature. Very few applications actually used renegotiation, but all
were affected. The use of PKI for peer authentication might fall in this

(2) Eliminate features which can reasonably be handled at the application
layer. To my mind, renegotiation for key/certificate change on long-lasting
connections falls in this category.

(3) Enable future security bug fixes to be handled by the industry standard
mantra, "Just upgrade to the latest version", instead of requiring hacks to
be compatible with versions back as far as SSL2. (I realize this is more of
a social than a technical goal.)

Cheers - Bill

Bill Frantz        |"After all, if the conventional wisdom was working, the
408-356-8506       | rate of systems being compromised would be going down, | wouldn't it?" -- Marcus Ranum