Re: [TLS] Protocol Action: 'Transport Layer Security (TLS) Renegotiation Indication Extension' to Proposed Standard

Paul Hoffman <> Tue, 12 January 2010 03:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA11B3A6897 for <>; Mon, 11 Jan 2010 19:40:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.925
X-Spam-Status: No, score=-5.925 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PI-CLebIl0cU for <>; Mon, 11 Jan 2010 19:40:37 -0800 (PST)
Received: from (Balder-227.Proper.COM []) by (Postfix) with ESMTP id EB7963A696A for <>; Mon, 11 Jan 2010 19:40:36 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.2/8.14.2) with ESMTP id o0C3eVNi085150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jan 2010 20:40:34 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p06240837c7719ebe83ca@[]>
In-Reply-To: <>
References: <>
Date: Mon, 11 Jan 2010 19:40:29 -0800
To: Brad Wetmore <Bradford.Wetmore@Sun.COM>,
From: Paul Hoffman <>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [TLS] Protocol Action: 'Transport Layer Security (TLS) Renegotiation Indication Extension' to Proposed Standard
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: Tue, 12 Jan 2010 03:40:37 -0000

At 6:55 PM -0800 1/11/10, Brad Wetmore wrote:
>Simon Josefsson wrote:
>> Still there are no guarantees that technical changes cannot happen
>> even after this point (due to appeals, major flaws discovered during
>> AUTH48, or something else), so a conservative vendor may be better off
>> waiting until the RFC has been published.
>Ignoring any appeals/changes/flaws for a second and considering just the
>best case scenario here...
>In looking over the RFC-editor's queue, I note we're close to the
>bottom.  The RFC-editor is saying they process things roughly FIFO, and
>I notice many things in the IETF stream standard track are in states
>EDIT/RFC-EDITOR/AUTH48) from Jan/May/Sept/Nov 2009.  Is this going to be
>several more weeks/months before this RFC is finalized, or are we
>getting this expedited?

Nothing is definitive. It is "likely" that there will be no technical changes between now and when the RFC is issued and therefore deployment can begin now. If there is a successful appeal, it could change, but those are rare. If the authors find technical mistakes, they can fix them before RFC publication, and this is becoming more common in the IETF (a situation that many of us find quite unfortunate).

--Paul Hoffman, Director
--VPN Consortium