Re: [TLS] Comments on TLS extension mechanism
David Hopwood <david.nospam.hopwood@blueyonder.co.uk> Sat, 24 June 2006 14:31 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9At-0000X3-Os; Sat, 24 Jun 2006 10:31:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9As-0000Wy-Cp for tls@ietf.org; Sat, 24 Jun 2006 10:31:50 -0400
Received: from smtp-out3.blueyonder.co.uk ([195.188.213.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu9Ar-0001gc-0p for tls@ietf.org; Sat, 24 Jun 2006 10:31:50 -0400
Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1Fu9Aq-00048c-EV for tls@ietf.org; Sat, 24 Jun 2006 15:31:48 +0100
Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out1.blueyonder.co.uk with esmtp (Exim 4.52) id 1Fu9Ap-0003KG-Iu for tls@ietf.org; Sat, 24 Jun 2006 15:31:47 +0100
Message-ID: <449D4CCF.8070107@blueyonder.co.uk>
Date: Sat, 24 Jun 2006 15:31:43 +0100
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: tls@ietf.org
Subject: Re: [TLS] Comments on TLS extension mechanism
References: <6b9359640606232306q664ed3b3h74bf12f916aae846@mail.gmail.com>
In-Reply-To: <6b9359640606232306q664ed3b3h74bf12f916aae846@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: david.nospam.hopwood@blueyonder.co.uk
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
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 <david.nospam.hopwood@blueyonder.co.uk> _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Comments on TLS extension mechanism Kyle Hamilton
- Re: [TLS] Comments on TLS extension mechanism David Hopwood
- Re: [TLS] Comments on TLS extension mechanism Kyle Hamilton
- Re: [TLS] Comments on TLS extension mechanism David Hopwood
- [TLS] SRP TLS extension status Peter Sylvester
- Re: [TLS] SRP TLS extension status Nikos Mavrogiannopoulos