Re: [TLS] Comments on TLS extension mechanism

["Kyle Hamilton" <[e-mail]>]

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.  There's
also nothing in place to keep experimental IDs from trampling on each
other.  (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.
Which is, as I understand it, approximately how the extensions are
supposed to work anyway.

Cordially,

-Kyle Hamilton

On 6/24/06, David Hopwood <[e-mail]> wrote:
> 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 <[e-mail]>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls