Subject: [TLS] Fwd: New Version Notification for draft-sandj-tls-iana-registry-updates-00.txt

From: Sean Turner <[email-masked]>
Date: Wed, 7 Sep 2016 14:57:32 -0400

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: [email-masked]
> 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" <[email-masked]>, "Sean Turner" <[email-masked]>, <[email-masked]>, "Joseph A. Salowey" <[email-masked]>
> 
> 
> 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
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Sep 2016 12:55:49 -0500

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:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls