[TLS] Setting Policy for Extensions
Eric Rescorla <ekr@rtfm.com> Wed, 27 July 2011 14:33 UTC
Return-Path: <ekr@rtfm.com>
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 ADE4B21F8574 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 07:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 K9DPvApK4yQ0 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 07:33:37 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E11DA21F8551 for <tls@ietf.org>; Wed, 27 Jul 2011 07:33:36 -0700 (PDT)
Received: by wwe5 with SMTP id 5so975937wwe.13 for <tls@ietf.org>; Wed, 27 Jul 2011 07:33:35 -0700 (PDT)
Received: by 10.227.58.74 with SMTP id f10mr128049wbh.22.1311777215123; Wed, 27 Jul 2011 07:33:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.145.209 with HTTP; Wed, 27 Jul 2011 07:33:15 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 27 Jul 2011 10:33:15 -0400
Message-ID: <CABcZeBPRXJ27LVRc3w5pyvi3wVqw=EHeKJt-SBoYHYLOeXwX6w@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [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: Wed, 27 Jul 2011 14:33:37 -0000
TLS WG members, The WG is starting to see an increasing number of proposals for new extensions, and it seems like it would be good to have a consistent policy for how to handle these. The chairs have gotten together with our AD and converged on the following draft policy, which we plan to discuss in the " Working Group Handling for Extensions to TLS" slot. Comments? -Ekr [For Joe and Eric] RFC 5246 defines an extensibility mechanism for TLS based on extensions signaled in the ClientHello and ServerHello. With TLS 1.2 and DTLS 1.2 being relatively stable, we are starting to see more proposed extensions, some of which, if used, represent significant changes to the TLS state machine. RFC 5246 requires IETF consensus for any extension. As there is an active TLS WG, this implies that extensions must be vetted with that WG. The following policy describes the level of review necessary for various types of proposed extension: 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. 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. 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. 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. 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. Best, -Ekr
- [TLS] Setting Policy for Extensions Eric Rescorla
- Re: [TLS] Setting Policy for Extensions Nikos Mavrogiannopoulos
- Re: [TLS] Setting Policy for Extensions Paul Wouters
- Re: [TLS] Setting Policy for Extensions Paul Hoffman
- Re: [TLS] Setting Policy for Extensions Nico Williams
- Re: [TLS] Setting Policy for Extensions Martin Rex
- Re: [TLS] Setting Policy for Extensions Paul Hoffman
- Re: [TLS] Setting Policy for Extensions Eric Rescorla
- Re: [TLS] Setting Policy for Extensions Eric Rescorla
- Re: [TLS] Setting Policy for Extensions Martin Rex
- Re: [TLS] Setting Policy for Extensions Nico Williams
- Re: [TLS] Setting Policy for Extensions t.petch