Subject: [TLS] Comments on TLS extension mechanism

From: "Kyle Hamilton" <[email-masked]>
Date: Fri, 23 Jun 2006 23:06:48 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: David Hopwood <[email-masked]>
Date: Sat, 24 Jun 2006 15:31:43 +0100

Kyle Hamilton wrote:
> 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 <[email-masked]>

---

From: "Kyle Hamilton" <[email-masked]>
Date: Sat, 24 Jun 2006 14:41:59 -0700

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

---

From: David Hopwood <[email-masked]>
Date: Sun, 25 Jun 2006 00:57:18 +0100

Kyle Hamilton wrote:
> 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

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

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 25 Jun 2006 19:18:42 +0200

- What is the current status of the identifier that is used for the SRP 
for TLS
  extension? Is the number 'reserved', for example?

- What is the status of decision making concern the treatment
  of that SRP-TLS by this group?

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 25 Jun 2006 20:43:13 +0200

On Sun 25 Jun 2006 19:18, Peter Sylvester wrote:
> - What is the current status of the identifier that is used for the
> SRP for TLS

Some weeks ago I tried to contact IANA to reserve it, but they said it 
was not possible. Now I see that they assigned this number to user 
mapping extension.

>   of that SRP-TLS by this group?

A final version of the draft will be issued during the next few days.

regards,
Nikos