Hi Sean, In general I support this but....
A stable, publicly available document is basically an RFC. So when the TLS WG says no that means asking an AD to sponsor or putting it into the Independent Stream process. So what it looks like you're doing is punting this problem into the lap of whoever is gonna be the Independent Stream Editor for this stuff because he or she will start getting a steady stream of requests for publication of documents describing a fabulous new TLS ciphersuite after the ADs tell everyone to "pound sand". I wonder if you have thought this through or prepped the stuckee? regards, Dan. On Tue, March 29, 2016 6: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. > > 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
