For the 16-bit fields, do we want to leave first-octet-zero values as IETF Consensus and leave 1-254 for Specification Required?
I suspect we'll need to wordsmith the text for the "Recommended" field in the cipher suite registry some; Standards-Track may or may not quite match up exactly with what we want (though it seems like it would be pretty good), but I would maybe say "for cipher suites marked 'No', it is possible that the cryptographic properties are not reviewed, and they may be bad or good". Should the session_ticket extension also be updated to point to this document (as was done for the new_session_ticket handshake message type)? I guess the security considerations should probably mention that making it easier for "anyone" to get a codepoint assigned comes with a risk that people will assume that having a codepoint means it's secure. The "Recommended" column attempts to address that, and software authors are encouraged to read the primary sources to determine the applicability of an entry to their software. Some minor notes on snippets of the document follow. The markdown-to-html conversion seems to have left long lines in sections 10 and 12; maybe there are some syntax errors around there? (Also, "however the value is computed different" should be "differently".) o Change the IANA registry policy [RFC5226 <https://tools.ietf.org/html/rfc5226>] for the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries. These more relaxes rules are more condusive to TBD. "relaxed". Huh, and thunderbird is also suggesting "conducive", that I missed. The TBD seems to be "experimentation and test deployment of draft specifications". o Add the designated expert intructions as a note to the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries to inform IANA- registry-focused, non-RFC-reading what's expected from the registry. "instructions" The "non-RFC-reading" compound adjective doesn't have an associated noun. "Readers" could work, but since "reading" is right there, maybe "viewers" is better. This document proposes no changes to the TLS Alert [I-D.ietf-tls-tls13 <https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-00#ref-I-D.ietf-tls-tls13>], TLS ContentType [I-D.ietf-tls-tls13 <https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-00#ref-I-D.ietf-tls-tls13>], TLS HandshakeType, [I-D.ietf-tls-tls13 <https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-00#ref-I-D.ietf-tls-tls13>] and TLS Certificate Status Types [RFC6961 <https://tools.ietf.org/html/rfc6961>]; Standards Action, for the 1st three, and IETF Review, for the last, are appropriate for these one-byte code points because of their scarcity. I think "registries" is missing after the list. In "The following extensions are only applicable to D/TLS protocol vesions prior to 1.3: truncated_hmac, srp, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info are not applicable to TLS 1.3." (another long line), the "only applicable [...] prior to 1.3" and "are not applicable to TLS 1.3" are redundant. Also, "versions" with an 'r'. -Ben On 09/07/2016 01:57 PM, Sean Turner wrote: > Here is a draft that proposes changes to a number of TLS-related registries, > e.g., adding notes to indicate orphaned extensions and registries, adding the > missing no_application_protocol alert. The motivation for this draft was to > not have everything that needs to be fixed be done in the TLS1.3 draft. > We’re positive it needs review. > > A repo for the draft can be found at: > https://github.com/seanturner/draft-sandj-tls-iana-registry-updates > PRs welcome. > > spt > >> Begin forwarded message: >> >> From: internet-dra...@ietf.org >> Subject: New Version Notification for >> draft-sandj-tls-iana-registry-updates-00.txt >> Date: September 07, 2016 at 14:10:25 EDT >> To: "Joe Salowey" <j...@salowey.net>, "Sean Turner" <s...@sn3rd.com>, >> <none-cha...@ietf.org>, "Joseph A. Salowey" <j...@salowey.net> >> >> >> A new version of I-D, draft-sandj-tls-iana-registry-updates-00.txt >> has been successfully submitted by Sean Turner and posted to the >> IETF repository. >> >> Name: draft-sandj-tls-iana-registry-updates >> Revision: 00 >> Title: D/TLS IANA Registry Updates >> Document date: 2016-09-07 >> Group: Individual Submission >> Pages: 8 >> URL: >> https://www.ietf.org/internet-drafts/draft-sandj-tls-iana-registry-updates-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-sandj-tls-iana-registry-updates/ >> Htmlized: >> https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-00 >> >> >> Abstract: >> This document changes the IANA registry policy for a number of D/TLS- >> related registries, renames some of the registries for consistency, >> and adds notes to many of the registries. As a result, this document >> updates many RFCs (see updates header). >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > _______________________________________________ > 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
