Hi Sean, I would like to express my opinion again.
I think the first requirement is great and sufficient. I have great support, appreciation and respect for the open source communities. However, the second requirement means that an IETF consensus can have no values in theory and that sounds not right to me. Regards, Quynh. ________________________________________ From: TLS <tls-boun...@ietf.org> on behalf of Hannes Tschofenig <hannes.tschofe...@gmx.net> Sent: Thursday, March 31, 2016 9:45 AM To: Sean Turner; <tls@ietf.org> Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites Hi Sean, What is the requirement for adding a spec to the list with the value IETF Recommended = "Y" (or to change an entry from "Y" to "N")? You mention two conditions: * IETF has consensus * Are reasonably expected to be supported by widely used implementations such as open-source libraries Of course, with all our work we expect them to be supported by widely used implementations. The future is unpredicable and therefore not a good item for making a judgement. I realy find document authors who have less interest to get their stuff deployed. Getting IETF consensus on specifications has turned to be easier than most people expect and the IETF published RFCs that have not received a lot of review. Large amount of review is not a pre-condition for consensus. While your idea sounds good it suffers from practical issues. I am worried that the process will not be too fair and may favor a certain type of community. Ciao Hannes On 03/30/2016 03:53 AM, 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. > > Thanks, > > J&S > > [0] In the last year, the chairs have received requests for: > > PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ > AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt > Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ > dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt > JPAKE: not sure they got around to publishing a draft. > > [1] > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
