Re: [TLS] Comments on TLS extension mechanism

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