Re: [TLS] Setting Policy for Extensions

Paul Wouters <> Wed, 27 July 2011 19:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19D5221F8BB7 for <>; Wed, 27 Jul 2011 12:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.526
X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XN4pbDBok-3y for <>; Wed, 27 Jul 2011 12:22:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E484D21F8BB4 for <>; Wed, 27 Jul 2011 12:22:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 180D757124; Wed, 27 Jul 2011 15:23:46 -0400 (EDT)
Date: Wed, 27 Jul 2011 15:23:45 -0400 (EDT)
From: Paul Wouters <>
To: Eric Rescorla <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: Wed, 27 Jul 2011 19:22:56 -0000

On Wed, 27 Jul 2011, Eric Rescorla wrote:

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

Overal I agree with the document, though I'd like to point out that
someones important use case can be totally irrelevant to someone elses set
of use cases, and the TLS group should try to be accomodating, providing
the proper security considerations are complied with. It is very easy to
say "I do not see a use for this new extension" which does run the risk
of stiffling new technologies. Though I also understand the need for
being conservative with a security protocol. I do think this document
balances the two properly. So I agree with the document as proposed.

But I do have some questions, partially based on my own recent submission
of a TLS extension draft.

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

I was under the impression that any standards document should have
TLS WG consensus and that extensions could not be an Informational?
In which case they can only be WG items. (note: this is one of the
reasons I brought my draft to the TLS WG instead of continuing for
an Individual / Informational RFC)

Would this document change that? I am not sure how relevant this
really is. When I started looking at TLS in more detail in the last
six months, I was pretty disappointed at the implementation of certain
TLS extensions. It seemed even a TLS 1.2 specification was not really
deployed anywhere, and neither were for example parts of RFC 6066.
(based on checking various apache and openssl code/sites)

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

I am not entirely sure if my draft would fall under this category, but
I think it does?

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

If it is really so intrusive to the TLS protocol, I would say it has to
be more then an item for another WG.

It is also a bit of a catch22. In my case, DANE awaits me to go to TLS,
and this paragraph would have TLS sent me back to DANE.

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