IETF Logo Mail Archive

[TLS] Generic process issues (Re: Re: draft-ietf-tls-renegotation: next)

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 16 December 2009 22:20 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 70D313A67AF for <tls@core3.amsl.com>; Wed, 16 Dec 2009 14:20:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.914
X-Spam-Level:
X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.132, 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 yV6mrlX+HPtp for <tls@core3.amsl.com>; Wed, 16 Dec 2009 14:20:21 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 1B3CC3A68C8 for <tls@ietf.org>; Wed, 16 Dec 2009 14:20:21 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBGMK6In018638 for <tls@ietf.org>; Wed, 16 Dec 2009 22:20:07 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 nBGMK61W010897 for <tls@ietf.org>; Wed, 16 Dec 2009 15:20:06 -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 nBGMCZwS005599; Wed, 16 Dec 2009 16:12:35 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBGMCZLw005598; Wed, 16 Dec 2009 16:12:35 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 16 Dec 2009 16:12:35 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <mrex@sap.com>
Message-ID: <20091216221234.GO1516@Sun.COM>
References: <200912162001.nBGK1K4I028293@stingray.missi.ncsc.mil> <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200912162059.nBGKx7Sv017923@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
Cc: "Kemp David P." <DPKemp@missi.ncsc.mil>, tls@ietf.org
Subject: [TLS] Generic process issues (Re: Re: draft-ietf-tls-renegotation: next)
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: Wed, 16 Dec 2009 22:20:22 -0000

On Wed, Dec 16, 2009 at 09:59:07PM +0100, Martin Rex wrote:
> So as far as rough consensus is concerned, it is definitely
> with the approach I described.  This is what the IETF procedures
> are about.  Otherwise we could just go back to counting votes.

Counting votes is problematic in an open membership organization.  Rough
consensus determination is a fairly subjective operation.  I.e., there's
going to be unhappy people no matter what.  But rough consensus is much
better than elections.

IMO we need a process for dealing with vulnerabilities in protocol
specifications.  Such a process should encourage disclosure to the IAB
and IESG, including permission for them to manage further disclosures to
other IETF participants, all so as to ensure private discussion of fixes
that approximates open discussions and avoids surprising the community
with faits accompli or nearly accompli.  (Regardless of what one thinks
happened in this case, handling of future cases like this one could be
horrible without such rules.)

Nico
--

v2.23.0 | Report a Bug | By Email