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, 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-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