Re: [TLS] Setting Policy for Extensions

"t.petch" <> Mon, 01 August 2011 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 677F411E8077 for <>; Mon, 1 Aug 2011 10:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lYAxeSQVBn2f for <>; Mon, 1 Aug 2011 10:00:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CD7B11E80AB for <>; Mon, 1 Aug 2011 10:00:52 -0700 (PDT)
Received: from (HELO pc6) ([]) by with SMTP id DVJ88264; Mon, 01 Aug 2011 18:00:48 +0100 (BST)
Message-ID: <054c01cc5063$bcda28a0$>
From: "t.petch" <>
To: "Eric Rescorla" <>, <>
References: <>
Date: Mon, 1 Aug 2011 17:57:34 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E36DBBF.0066, actions=tag
X-Junkmail-Status: score=10/50,
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4E36DBCA.0004, ss=1, fgs=0, ip=, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Subject: Re: [TLS] Setting Policy for Extensions
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Aug 2011 17:00:54 -0000

I am unclear where this is going to go, such that those with an interest
in it, in proposing or reviewing extensions, know that it exists and can
access it.  We have I-Ds, RFCs, we have a Charter and .... Where can it go?
(If it belongs in an RFC, then it should have gone into RFC5246:-(

Also, I think that it should contain a sunset clause, that is that whatever we
agree on applies as long as there is a TLS WG, and that the topic
must be revisited if and when the TLS WG is shut down - I do not
think that the TLS WG should legislate for when it has ceased to exist:-)

On a practical point, I would like the IETF LC to have a minimum period, 
say 8 weeks.  Independent Submissions are sometimes slipped through
with a Last Call of two weeks, which, I believe, has been insufficient for
the IETF to review an I-D adequately (cannot recall a specific example
but I can remember thinking it on a number of occasions).

Tom Petch

----- Original Message ----- 
From: "Eric Rescorla" <>
To: <>
Sent: Wednesday, July 27, 2011 4:33 PM
Subject: [TLS] Setting Policy for Extensions

> 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 mailing list