Re: [TLS] Setting Policy for Extensions

[Paul Hoffman <[e-mail]>]

On Jul 27, 2011, at 10:33 AM, Eric Rescorla wrote:

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

The person who gets to define "significant" and "resolved" controls all extensions, then. It would be better if they were defined more fully here.

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

OK, add "unobjectionable" to the list above.

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

Why is adding a message so important here? Who defines what changes the "TLS model" or "TLS state machine?

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

Who defines "level of interest"? If there is a document that is fairly trivial and also gets little interest, is it prohibited from progressing by this rule?

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


Overall: The proposed rules above seem to be about the same as the unspoken rules today, with the difference being that they are stated but completely unclear. It doesn't feel like this is an improvement over the current situation.

--Paul Hoffman