[TLS] Comments on TLS extension mechanism
"Kyle Hamilton" <aerowolf@gmail.com> Sat, 24 June 2006 06:06 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu1IG-00065G-GN; Sat, 24 Jun 2006 02:06:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu1IF-0005vL-E5 for TLS@lists.ietf.org; Sat, 24 Jun 2006 02:06:55 -0400
Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu1ID-0004OX-N2 for TLS@lists.ietf.org; Sat, 24 Jun 2006 02:06:54 -0400
Received: by nf-out-0910.google.com with SMTP id m19so351961nfc for <TLS@lists.ietf.org>; Fri, 23 Jun 2006 23:06:48 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FIePGRZXh9zWUHg1F8Q5dpFrUFywydigoimjfgiLX1QrCPGMihhzRwtZjGbmrx6vF61486ulCR54iaH3gZSoljxyzs56KORiri7BWifyZujZMdW4HZqwLJmImx99MAvqoKfAvMwgC72vgYWgSQMY+eIWPU0+VrUkIkvyyo7QD8M=
Received: by 10.49.54.13 with SMTP id g13mr3162545nfk; Fri, 23 Jun 2006 23:06:48 -0700 (PDT)
Received: by 10.48.12.1 with HTTP; Fri, 23 Jun 2006 23:06:48 -0700 (PDT)
Message-ID: <6b9359640606232306q664ed3b3h74bf12f916aae846@mail.gmail.com>
Date: Fri, 23 Jun 2006 23:06:48 -0700
From: Kyle Hamilton <aerowolf@gmail.com>
To: TLS@lists.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc:
Subject: [TLS] Comments on TLS extension mechanism
X-BeenThere: tls@lists.ietf.org
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." <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
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. If this is not the appropriate forum, please let me know. -Kyle Hamilton _______________________________________________ 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