Re: [TLS] Setting Policy for Extensions
"t.petch" <ietfc@btconnect.com> Mon, 01 August 2011 17:00 UTC
Return-Path: <ietfc@btconnect.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 677F411E8077 for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 10:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
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 lYAxeSQVBn2f for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 10:00:53 -0700 (PDT)
Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD7B11E80AB for <tls@ietf.org>; Mon, 1 Aug 2011 10:00:52 -0700 (PDT)
Received: from host109-153-78-164.range109-153.btcentralplus.com (HELO pc6) ([109.153.78.164]) by c2bthomr14.btconnect.com with SMTP id DVJ88264; Mon, 01 Aug 2011 18:00:48 +0100 (BST)
Message-ID: <054c01cc5063$bcda28a0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Eric Rescorla <ekr@rtfm.com>, tls@ietf.org
References: <CABcZeBPRXJ27LVRc3w5pyvi3wVqw=EHeKJt-SBoYHYLOeXwX6w@mail.gmail.com>
Date: Mon, 01 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-Premium-Raw: score=7/50, refid=2.7.2:2011.8.1.155415:17:7.586, ip=109.153.78.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4E36DBCA.0004, ss=1, fgs=0, ip=0.0.0.0, 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-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: 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" <ekr@rtfm.com> To: <tls@ietf.org> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- [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