Re: [TLS] Comments on TLS extension mechanism

David Hopwood <david.nospam.hopwood@blueyonder.co.uk> Sat, 24 June 2006 23:57 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuI0G-0002r2-Mb; Sat, 24 Jun 2006 19:57:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuI0E-0002qx-Lx for tls@ietf.org; Sat, 24 Jun 2006 19:57:26 -0400
Received: from smtp-out5.blueyonder.co.uk ([195.188.213.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuI0D-0001mi-9u for tls@ietf.org; Sat, 24 Jun 2006 19:57:26 -0400
Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FuI0C-000099-DD for tls@ietf.org; Sun, 25 Jun 2006 00:57:24 +0100
Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out6.blueyonder.co.uk with esmtp (Exim 4.52) id 1FuI0B-0006zt-UO for tls@ietf.org; Sun, 25 Jun 2006 00:57:24 +0100
Message-ID: <449DD15E.1090100@blueyonder.co.uk>
Date: Sun, 25 Jun 2006 00:57:18 +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> <449D4CCF.8070107@blueyonder.co.uk> <6b9359640606241441g5c795fej49fdc6d25961c736@mail.gmail.com>
In-Reply-To: <6b9359640606241441g5c795fej49fdc6d25961c736@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
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:
> Because, as I understand it, within every protocol (including IP)
> there has been a specific item dedicated to research.  There is
> certainly no current shortage of IDs... but there's also nothing in
> place to provide a mechanism when resource exhaustion occurs.

When and if 60000 IDs have been exhausted, I promise to revisit this
question.

(Note that this would require 13 times more RFCs describing TLS extension
mechanisms, assuming one RFC per extension, than the current total number
of published RFCs.)

> There's also nothing in place to keep experimental IDs from trampling
> on each other.

Assigning IDs for experiments has pros and cons. In general, for numbers
where there is no range allocated to experiments, there is an implied
obligation on the experimenter to make sure that an implementation that
supports the experiment is not used on a public network in such a way
that it could cause disruption to other network users.

In any case, the time to raise this issue would have been when RFC 4366
was being discussed. The next opportunity to change the policy is when
the extension mechanism is incorporated into TLS 1.2.

> (In this particular case, I'd like to inform the other end of
> what security policy this computer must implement, and determine if
> there is a compatible mapping before continuing the connection.  This
> determination is not something that any current protocol does, and I
> want to research the security issues with such an action as this
> before I make any kind of proposal about it.)
> 
> If you're worried about "increasing the complexity of the current
> parser", put a length integer just after the extension ID so the
> parser knows how much to skip if it doesn't understand the extension.

The issue is unnecessary complexity for implementations that do understand
the extension, not for implementations that do not understand it.

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>;



_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls