Re: [TLS] Comments on TLS extension mechanism

David Hopwood <> Sat, 24 June 2006 14:31 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1Fu9At-0000X3-Os; Sat, 24 Jun 2006 10:31:51 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Fu9As-0000Wy-Cp for; Sat, 24 Jun 2006 10:31:50 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Fu9Ar-0001gc-0p for; Sat, 24 Jun 2006 10:31:50 -0400
Received: from [] (helo=anti-virus01-08) by with smtp (Exim 4.52) id 1Fu9Aq-00048c-EV for; Sat, 24 Jun 2006 15:31:48 +0100
Received: from ([] helo=[]) by with esmtp (Exim 4.52) id 1Fu9Ap-0003KG-Iu for; Sat, 24 Jun 2006 15:31:47 +0100
Message-ID: <>
Date: Sat, 24 Jun 2006 15:31:43 +0100
From: David Hopwood <>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Subject: Re: [TLS] Comments on TLS extension mechanism
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
X-Mailman-Version: 2.1.5
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: <>, <>

Kyle Hamilton wrote:
> I would like to request that a specific TLS extension number, say
> 65534, be used as a means of negotiating arbitrary TLS extensions for
> specific application and research purposes, with the express
> understanding that this mechanism SHOULD NOT be used unless no other
> option presents itself, AND the implementor is aware of any potential
> security issues that may be introduced.  The format I propose would be
> akin to:
> struct {
>   int extension_ID,
>   OID arbitrary_extension,
>   int extension_data_length(65535)
>   opaque(arbitrary_extension_data)
> } TlsArbitraryExtensionType;
> Since section 5 of RFC4366 (and predecessors) states that new
> extensions shall ONLY be approved through RFCs approved by the IESG,
> this is the only logical place to propose such that I can find.

Why would we want to approve an extension that essentially bypasses
the current approval policy, which was agreed by concensus of the
TLS WG, and that also increases the parsing complexity of such extensions
for no good reason?

There is no extension ID scarcity problem. The policy for approval of
new extensions is exactly as intended, and the lack of an experimental
ID range is quite deliberate:

   The list of extension types, as defined in Section 2.3, is maintained
   by the Internet Assigned Numbers Authority (IANA).  Thus, an
   application needs to be made to the IANA in order to obtain a new
   extension type value.  Since there are subtle (and not-so-subtle)
   interactions that may occur in this protocol between new features and
   existing features that may result in a significant reduction in
   overall security, new values SHALL be defined only through the IETF
   Consensus process specified in [IANA].

   (This means that new assignments can be made only via RFCs approved
   by the IESG.)

David Hopwood <>

TLS mailing list