Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites

[Sean Turner <[e-mail]>]

On Apr 06, 2016, at 12:21, Aaron Zauner <[e-mail]> wrote:
> 
> Hi,
> 
>> On 30 Mar 2016, at 03:53, Sean Turner <[e-mail]> wrote:
>> 
>> Hi!
>> 
>> In Yokohama, we discussed changing the IANA registry assignment rules for cipher suites to allow anyone with a stable, publicly available, peer reviewed reference document to request and get a code point and to add an “IETF Recommended” column to the registry.  This change is motivated by the large # of requests received for code points [0], the need to alter the incorrect perception that getting a code point somehow legitimizes the suite/algorithm, and to help implementers out.  We need to determine whether we have consensus on this plan, which follows:
>> 
>> 1. The IANA registry rules for the TLS cipher suite registry [1] will be changed to specification required.
>> 
>> 2. A new “IETF Recommended” column will be added with two values: “Y” or “N”.  Y and N have the following meaning:
>> 
>> Cipher suites marked with a “Y” the IETF has consensus on
>> and are reasonably expected to be supported by widely
>> used implementations such as open-source libraries.  The
>> IETF takes no position on the cipher suites marked with an
>> “N”.  Not IETF recommended does not necessarily (but can)
>> mean that the ciphers are not cryptographically sound (i.e.,
>> are bad).  Cipher suites can be recategorized from N to Y
>> (e.g., Curve448) and vice versa.
>> 
>> 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that matches the above so that the same information is available to those who don’t read the IANA considerations section of the RFC.
>> 
>> Please indicate whether or not you could support this plan.
> 
> I maintain the OCB draft and I do support this idea. Sorry for joining this thread late. I did however vote on it during the meeting on monday.
> 
> What's still unclear to me from the discussion is what suites would get a Y or N and which suites won't. Are we just talking about WG consensus or does implementation-availability weigh in here? It's not perfectly clear to me how this would be decided; just because the IANA registry flags a certain suite as preferred doesn't mean it actually will be implemented, and vice-versa. Library authors sometimes implement algorithms out of pure interest and love for coding. I, too, think going beyond a simple Y/N would just further complicate things for implementers and people trying to understand the IANA registry.
> 
> Aaron

What we’re talking about is IETF consensus (i.e., it’s got to get through an IETF LC which is slightly higher than just a WGLC), but we’d do a one sentence tweak to the TLS WG charter to make the TLS WG be the entity that determine whether there’s a Y or N.

A “Y” does not guarantee that it will be implemented and that’s why we put "and are reasonably expected to be supported by widely used implementations such as open-source libraries.”  Those are pretty good weasel words, but since there’s no protocol police we can’t really say they will be implemented.  On the other hand, open source implementations also have their own pressures they have to deal with that I’m not sure should automatically impact the list.  I also am worried about just adding algorithms that are in an open source implementation because I believe just about everybody that’s requested a code point starts the conversation out with “I’ve got this OpenSSL patch …. "

spt