I apologize in advance; this is about process so it’s long. On Mar 30, 2016, at 01:29, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi Sean > > I also strongly support this. I’m just wondering how we plan to enforce the > "stable, publicly available, peer reviewed reference” part. As your examples > below show, the reference tends to be an I-D. That’s stable and publicly > available, but we have no idea if it’s peer reviewed or who the author’s > peers are.
Note that I think both the cipher suite assignment specification and the algorithm specification need to be "stable, publicly available, peer reviewed reference.” Normally, the former informatively refers to the latter. [0] The algorithm specification is not always an RFC, but the cipher suite assignment specifications have been; this plan changes that under certain circumstances (see below). As far as stable and publicly available are concerned, these are part of the process now, as specified in [1] (and if the update ever gets done in [2]): Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. This definition gives power/discretion to the designated expert (it’s ekr btw). We can: a) defer to the expert's judgement (some of what they are to do is in [1][2]), or b) write some rules for the IANA considerations section that they’ll follow. I think that a) has worked in the past and would continue to work in the future, but b) couldn’t hurt. If we go for a) then if the expert is ever unsure, they can just ask the AD/WG chair/community for guidance [3][4]. Beware that the text for b) will be like a bright light for process moths [5]. As far as peer review, this is where the silent “c” in team comes to play (c is for community). If the expert is not sure, then they'd ask the AD/WG chair/community for guidance. We could also use b) to provide some rules, which could include references to BCP 61 [6] (and for MTI algs [7]). > One other thing, in some of the links you pasted below you give a specific > draft version (like > https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt) while for > the others you give the generic version (like > https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/). The former is stable > but the latter is not. Are the authors free to keep modifying the > specification after getting the code point? Sorry I wasn’t clear. The references I listed were not supposed to imply stability they were just the list of cipher suites Joe and I have received requests from over the past year. I don’t think that authors are free to keep modifying their specification after getting a code point, because of the Specification Required definition [8]. Some other things we should be clear on: 1. All of the drafts referenced and the future drafts requesting code points do *not* need to come through the WG. But, I do think drafts that want a “Y” need to come through, and we shouldn’t kid ourselves most folks will want the “Y”. How does this sound (here I assume the algorithms are already published elsewhere i.e., this is just for the assignments): a) For MTI and “Y” requests, a.1) requester’s publish individual draft, a.2) requester’s ask for wg adoption, a.3) wg chairs do adoption call, a.4) wg does its thing on wg draft, a.5) ietf does its thing, and a.6) iana (assigns #s) & rfc editor (publishes) do their things. b) For all others: b.1) request is submitted to IANA, WG, WG chair, AD, b.2) request is redirected to designated expert, b.3) designated experts reviews request: -- if good-to-go designated expert tells IANA to assign code point (goto b.4) -- if not-good-to-go for an obvious reasons the designated expert rejects the request with some rationale (and probably lets the sec ADs know about it) -- if not-good-to-go for all other reasons the designated expert asks (expert's choice depending on the situation) AD/WG chairs/community for guidance b.4) iana makes assignment and includes the cipher suite assignment specification reference in the registry (and possibly the rfc editor does their thing if an RFC is being published) Early assignment rules can still apply to a) and b). 2. As far as draft-ietf-tls-pwd, we need to decide whether it should continue as a WG draft or free Dan to pursue other publication avenues. 3. We should avoid a long list of “updates” to TLS1.3 RFC#-to-be when new cipher suites get added. Drafts should only include an “updates” header if we’re modifying the MTIs or we’re adding a new “Y” cipher suite because we only expect all implementations to support these cases. 4. WRT language - I’m assuming we’d continue to have English versions of the algorithm specification. spt [0] One reason is that the CFRG doesn’t publish standards track RFC so the references to algorithm specifications that come through the CFRG need to be informative. [1] https://datatracker.ietf.org/doc/rfc5226/ [2] https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ [3] No worries - there is of course process to replace rouge experts, for experts to appeal said decision [3a], etc. [3a] Section 6.5.1 of https://datatracker.ietf.org/doc/rfc2026/ [4] If history is any guide, I doubt the TLS mailing list is going to go away even if the WG closes (e.g., mailing lists for stalwarts like PKIX, SMIME, SSH are still around). [5] Note that I very much want to avoid the following very deep and very dark rat hole: establishing an IANA registry of approved reference organizations/sites/etc. that the expert can refer to for a “free pass” org/sites/etc. {rant: [~5~]} [~5~] { rant: If we do go down this rat hole, I’ve got some specific organizations in mind that we should ban from ever being included in this list until they publicly state that they’ll allow normative references to IETF RFCs in their documents/standards/etc. And, now that I think about it maybe we’d include some country’s too. (I warned you it was a rant) } [6] https://datatracker.ietf.org/doc/rfc3365/ [7] https://datatracker.ietf.org/doc/draft-rsalz-drbg-speck-wap-wep/ [8] I’m sure this rule has been broken at some point in the past, but it’s not one I’m advocating that we break it on a regular basis. > Yoav > >> On 30 Mar 2016, at 4:53 AM, 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. >> >> 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
