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

[Benjamin Kaduk <[e-mail]>]

On 03/29/2016 08:53 PM, Sean Turner 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 support this plan (with the expectation that the IANA "specification
required" rules take precedence over the informal text in this mail
about a "stable, publicly available, peer reviewed reference document",
as Yoav noted as a potential issue).

I am not sure that we want to be in the business of explicitly marking
things as insecure other than our own RFCs, though -- there could be an
implication of more review than is actually the case, which is what this
proposal is trying to get rid of.

-Ben