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

[Hannes Tschofenig <[e-mail]>]

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