[TLS] protocol registry issues (was SPDY / NPN)

[Patrick Pelletier <[e-mail]>]

Martin Rex wrote:

> The issue with too strict rules is that it may simply get ignored,
> and code points be "kidnapped".  So overly strict rules can result
> in an near complete loss of control over people&ideas whose time has  
> come.
>
> "It's easier to ask forgiveness than it is to get permission."

It seems that ssh has a better way to handle this "experimental  
deployment" phase, since it uses strings, and allows domain-qualified  
private names.  (RFC 4250, section 4.6.1)

What about an extension that would allow TLS to do a similar thing?   
The extension would be sent by the client, and would declare its  
interpretation of "Private Use" numbers, by associating each number  
with a string.  (Which would have the "[e-mail]" format of ssh  
private names.)  Then, if the server understood this extension, it  
would simply use the Private Use numbers that the client proposed.

Once IANA allocates a number, the client can use the IANA-allocated  
number in its list of number/string pairs, instead of a Private Use  
number, so that it can interoperate both with servers that support  
this "number to string" extension but don't yet know about the new  
IANA number, and also with servers that do know about the IANA- 
allocated number, but don't support the "number to string" extension.   
Once enough servers know about the IANA-allocated number, the clients  
can stop listing it in their "number to string" list, to save space.

This would work for any registry which has a "private use" range,  
which from a quick look at the IANA registry, looks like: TLS  
Certificate Types, TLS ClientCertificateType Identifiers, TLS Cipher  
Suites, EC Named Curves, EC Point Formats, EC Curve Types, TLS  
Supplemental Data Formats, TLS UserMappingTypes, TLS  
SignatureAlgorithms, TLS HashAlgorithms, TLS Authorization Data  
Formats, and TLS Compression Method Identifiers.

There are some registries which don't have "private use" areas, so  
IANA would need to allocate a "private use" range in order to use them  
with this extension.  That would include: TLS ContentTypes, TLS  
Alerts, TLS HandshakeTypes, Heartbeat Message Types, Heartbeat Modes,  
and ExtensionTypes.

It seems like this would be an easy way to avoid the  
"kidnapping"/"number camping" problem.

--Patrick