[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