[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