Re: [TLS] Query for consensus on an "experimental/private-use" extension identifier

[Kyle Hamilton <[e-mail]>]

On Thu, Dec 17, 2009 at 2:25 PM,  <[e-mail]> wrote:
> The "IETF Consensus" number allocation process is described in RFC
> 2434: it means writing an Internet-Draft, and getting it published
> as an IETF stream RFC (the actual allocation happens when the
> draft has been approved by the IESG).

Alright.  I'm just asking you (in your AD hat, thus this is an "IETF
Submission" under RFC2434):  Is there a particular way I have to use
the I-D submission tool?  Or do I just write an I-D that conforms to
the IETF format, upload it, and call it
'draft-hamilton-tlsext-private-allocation.txt' or something?

> However, I'd like to add that often such "private use" identifiers are
> intentionally designed so that they would trample over each other (so
> that they only work for private use/mutually agreed experiments, and
> are not used just to avoid going through the IETF process).
>
> If we, for example, created a "private use" extension where the first
> 4 bytes are the Enterprise Number (which anyone can get just by
> filling a web form), the effect would probably be pretty much the same
> as changing the IANA allocation policy for the whole registry to
> "First Come First Served".

Nobody would be forced to either use it or act on it, and it is a
viable mechanism for extensions that applications actually find
themselves needing (in my case, I need to obscure both the list of CAs
that the peer acting as the server will accept and the list of CAs
that the peer acting as the client will accept, in a way that is
noncompliant with the TLS specification).  I actually have a PEN,
22232.  I was thinking of making the first part of the extension be
the OID, in text form, of the extension.  Nobody would have to
interact with one that they do not understand.  (If an extension is
offered by the client, and is not recognized by the server, the server
doesn't send it back.  The client then has the option of continuing or
aborting the connection.  This was all specified as part of TLSEXT,
and I can't see anyone who's actually implementing a different
security policy than the one I have to work with actually doing
anything with the data therein (that's tagged with my policy) -- it
would only be able to be used by implementations that understood it,
and still be in the handshake message hash for those implementations
that didn't.)

The problem that exists in the the TLS WG is that it (collectively)
thinks its members knows everything, every possible location where its
protocol could be used, and thus every possible policy that it could
possibly be wanted to run under.  This leads the TLS WG to attempt to
encode what they think policy should be ('an unauthenticated server
MUST NOT send a ClientCertificateRequest; if it does, the client MUST
terminate with a fatal handshake_error') into absolute requirements in
technical documents, which is an absolute mistake.

I have several ideas that would extend the range of policies that can
be used in TLS -- among others, an election protocol for two peers,
neither of which believing it's a server or a client -- perhaps a peer
to peer protocol that says "we know how to do TLS" so that they just
operate in conjunction with each other, to essentially 'draw lots' for
who the server should be.  I'm also playing around with an idea where
a TLS-capable file descriptor is opened to a listener which
immediately sends a ClientHello, not a ClientHelloRequest.  I'm
playing around with them (they require a modification of the handshake
protocol sequence), but I do have a concrete reason why I need an
extension: the definition of "acceptable CA names", as it exists in
the TLS specification, cannot be changed among compliant
implementations.  In my case, I'm working with a bunch of peers, most
of which don't want to advertise in the clear that each accepts a
particular CA.

Since there's no way to know which CAs a particular peer works with
(the entire reason for the "acceptable CA list" in SSLv3 and TLS),
this means that I need to shash all of the names of CAs that the
client-cert holder has, and I need to be able to match them on the
peer with the list of acceptable CAs.  This is arguably the same
operation as sending "what CAs I will accept" from the server to the
client, and thus already belongs in the handshake hash.  Since I'm
trying to minimize the disruption to the protocol, this requires
either an extension, or the use of an additional record type (which
I'm not comfortable using, because it won't be included as part of the
handshake calculation).

The fact is that the working Area you are the Director of isn't really
motivated to provide workable security.  Each member is only motivated
to provide *the best security that they themselves need*.  Security is
a bunch of trade-offs, and one of them is "Secure so that the cost of
breaking the security is only slightly beyond the value of what is
secured".  In the grand scheme of things, TLS could have been made a
lot more generalized, and more people beyond SMTP and HTTP would
actually use it.

Since the range of available extension numbers is 15-34, I can't
simply ask for one for a single application.  I aim for my application
(and TLS implementation) to be compliant with the spec; I'm simply
stuck under additional constraints/requirements that TLS can not and
will not flex to accommodate.

Thus, my desire is for an extension that can be used for private
signalling among implementations that understand it.  There isn't even
a 'private use' allocation, much less a 'research' allocation.  And
that's just moronic.  (Or maybe it isn't.  Forcing entities which
understand this extension to do a sanity check on the data it
contains, rather than blindly accepting it, might do wonders for
increasing error detection rates.  Then again, my cynicism says it
won't.  Either way, I have a legitimate private need to be able to use
an extension that otherwise doesn't exist.)

I'd rather have a single extension that can have multiple semantics
than a single extension for each possible semantic; because of this,
it requires a means of signalling which semantic to use for it.  I'd
also like to see the more successful semantics break out of the
private-use extension mold and into standardized semantics, while the
less successful ones fade back into the primordial soup of unrealized
ideas.

-Kyle H