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

Benjamin Kaduk <bkaduk@akamai.com> Tue, 13 September 2016 17:55 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA099128874 for <tls@ietfa.amsl.com>; Tue, 13 Sep 2016 10:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWJUAvmvC4Uk for <tls@ietfa.amsl.com>; Tue, 13 Sep 2016 10:55:51 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7596B126D74 for <tls@ietf.org>; Tue, 13 Sep 2016 10:55:50 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AC6B5433443; Tue, 13 Sep 2016 17:55:49 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 94535433442; Tue, 13 Sep 2016 17:55:49 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1473789349; bh=ZKOkPGCotP11hQqxRRN8Zi9f/f8NUzJk3MCWXiIdGzA=; l=12786; h=To:References:From:Date:In-Reply-To:From; b=vP5oSR8D35W+dl6jMsievSr0Qa1+Unua3MNpfho5zOdl4PI+BBsf8F8shuTf/rsLq M60zIhXd8Fxd8BPbJjHnEB27ZlEBN3wpGpT/01d7uSH7S1qzwlWRKrGi4+z7BKjDMo Jo2KX7H5AFtAvGJE2tEAZJayvzebDROg7dSZ3BBo=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 534ED1FC8B; Tue, 13 Sep 2016 17:55:49 +0000 (GMT)
To: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
References: <147327182554.22374.17570991017015027030.idtracker@ietfa.amsl.com> <F8C75EF0-B18A-46FC-BC48-5BF9055500B1@sn3rd.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <aa5a8208-68e5-8f33-950e-7bc935913776@akamai.com>
Date: Tue, 13 Sep 2016 12:55:49 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <F8C75EF0-B18A-46FC-BC48-5BF9055500B1@sn3rd.com>
Content-Type: multipart/alternative; boundary="------------70B2623EE12ED1DCDC9690E6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h6oZz795BmFrXk3_bKK-KMhbJsY>
Subject: Re: [TLS] Fwd: New Version Notification for draft-sandj-tls-iana-registry-updates-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2016 17:55:54 -0000

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-drafts@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" <joe@salowey.net>, "Sean Turner" <sean@sn3rd.com>, <none-chairs@ietf.org>, "Joseph A. Salowey" <joe@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