Re: [TLS] Setting Policy for Extensions

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 28 July 2011 00:49 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847B321F8B2D for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 17:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.419
X-Spam-Level:
X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ6IZj77XWrD for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 17:49:06 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A952F21F8B2B for <tls@ietf.org>; Wed, 27 Jul 2011 17:49:05 -0700 (PDT)
Received: from dhcp-2121.meeting.ietf.org (dhcp-2121.meeting.ietf.org [130.129.33.33]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6S0mk4p099424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <tls@ietf.org>; Wed, 27 Jul 2011 17:48:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CABcZeBPRXJ27LVRc3w5pyvi3wVqw=EHeKJt-SBoYHYLOeXwX6w@mail.gmail.com>
Date: Wed, 27 Jul 2011 20:49:03 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6965DB76-72C3-4AC1-92F5-699B8A2E4337@vpnc.org>
References: <CABcZeBPRXJ27LVRc3w5pyvi3wVqw=EHeKJt-SBoYHYLOeXwX6w@mail.gmail.com>
To: tls@ietf.org
X-Mailer: Apple Mail (2.1084)
Subject: Re: [TLS] Setting Policy for Extensions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Thu, 28 Jul 2011 00:49:06 -0000

On Jul 27, 2011, at 10:33 AM, Eric Rescorla wrote:

> 1. All extensions to TLS (including AD sponsored extensions) must
> minimally be sent explicitly to the TLS WG prior to or during IETF LC.
> If that process surfaces significant objections, then these objections
> should be resolved prior to publication. For trivial extensions, this
> process is sufficient. An example of a trivial extension would be
> signaling for a new TLS Exporter (RFC 5705), as this has no impact on
> TLS proper.

The person who gets to define "significant" and "resolved" controls all extensions, then. It would be better if they were defined more fully here.

> 2. All non-trivial extensions (i.e., anything which alters TLS
> processing in some way) must be presented to the TLS WG and at least
> be considered unobjectionable.

OK, add "unobjectionable" to the list above.

> They need not be WG items.  Extensions
> in this category can proceed without widespread WG support, but must
> either have no significant objections or achieve WG consensus to
> proceed.  An example of a non-trivial extension would be one that
> defined a new form of MAC truncation. This alters TLS processing but
> not the state machine.
> 
> 3. Extensions which which involve significant changes to the TLS
> model/state machine, adds new messages, etc. must be TLS WG work
> items, or, if primarily designed for some other WG, must be work items
> of that WG and developed in collaboration with the TLS WG and subject
> to the WG consensus process.

Why is adding a message so important here? Who defines what changes the "TLS model" or "TLS state machine?

> Extensions in this category will
> generally need to show significant amounts of non-author support in
> order to proceed.  Particular attention will be paid to the impact of
> such extensions on the TLS architecture and the impact on potential
> future extensions. An example of such an extension would be TLS
> Tickets (RFC 4507), because it involved redoing the resumption state
> machine and adding a new TLS message.
> 
> 
> The WG considers it an important objective to to provide timely,
> clear dispositions of new efforts. Work will be taken on when there is
> consensus and based on the WG's estimate of the level of interest and
> the size and priority of the current workload.

Who defines "level of interest"? If there is a document that is fairly trivial and also gets little interest, is it prohibited from progressing by this rule?

> Reconsideration of
> proposals which have failed to gather consensus will be prioritized
> behind proposals for new work which have not yet been considered.
> In general, requests for reconsideration should only be made once a
> proposal has been significantly revised and there is evidence of
> substantial level of community support.


Overall: The proposed rules above seem to be about the same as the unspoken rules today, with the difference being that they are stated but completely unclear. It doesn't feel like this is an improvement over the current situation.

--Paul Hoffman