Re: [TLS] Setting Policy for Extensions

["t.petch" <[e-mail]>]

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" <[e-mail]>
To: <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls