Hi, > On 30 Mar 2016, at 03:53, Sean Turner <s...@sn3rd.com> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls