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

["Dan Harkins" <[e-mail]>]

  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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>