Re: [TLS] AD Review, WAS: Re: WGLC for draft-ietf-tls-iana-registry-updates-03.txt

Sean Turner <sean@sn3rd.com> Thu, 01 February 2018 00:23 UTC

Return-Path: <sean@sn3rd.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 16859130EF3 for <tls@ietfa.amsl.com>; Wed, 31 Jan 2018 16:23:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 WpMJrco4yu4w for <tls@ietfa.amsl.com>; Wed, 31 Jan 2018 16:23:43 -0800 (PST)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D189C12EB46 for <tls@ietf.org>; Wed, 31 Jan 2018 16:23:42 -0800 (PST)
Received: by mail-qt0-x22d.google.com with SMTP id g14so24322004qti.2 for <tls@ietf.org>; Wed, 31 Jan 2018 16:23:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TpQhdkT7Nu19Mfe8sRvRppnANLMuFeMszgNdP2tXd/Y=; b=lQSbbXn19XPcbtys0ki7iaQdHaCMCzPP62Wxn1y7Fs5kpyG+GM47L24anpwFDN4oCB 8g82uPV4b+cQakb52WXaNj95g2TdcBkA1sUfkZP6VYk9zVjDXUH1RyBomb31oCjTPRQm i7HVfOLUyfG4St0zO/7Z3zJByC5v9ZP34hEso=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TpQhdkT7Nu19Mfe8sRvRppnANLMuFeMszgNdP2tXd/Y=; b=P9ZuRjSMQHM7E/WccQ8fHPtd+6uJ49/lV8TQ3lp1RqeMkjm80jq/XZM2iYMMGDm8KI axWuDJhwZg7HuuDGhOEN9UOuD8CzoJaX47CUK8N01WsJ/hDuphSO+P8fnmYaG6pE1YeV wMnFPJ9YrCkItNDvrkcmah/quBBGv3ONVIlDQn+MrlJqqEPbSmEROQxEELLGw1UdOqzw sEVIRLa7H/9KGgaSuKBgg7Ptr6jPJYntPrriokx+e601ZT+5brlyho4DxZHa2MSp/t1d FII8QyL0qyGgdVChp5KXr9Chu2jsHMCQNBjrZzCXYeBs8lRobM0/i4wBDy9j6kMdZj3q GeBQ==
X-Gm-Message-State: AKwxytd/b/mPV0bBrmTfNoMMuWuFfcV2awsg+XwBpn/Cu6P80b6cy7G+ pXItRdf2lesu0abHjO5rXT9ZN8cN14Q=
X-Google-Smtp-Source: AH8x226dzLpo9Rx90EzkHjkIXv7GbGRxf4axlsdWUMkhpCk35iA56GQw61lW6MiUwsUiMpci1cz2ww==
X-Received: by 10.200.35.113 with SMTP id b46mr53979004qtb.262.1517444621782; Wed, 31 Jan 2018 16:23:41 -0800 (PST)
Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id x1sm10956267qkd.77.2018.01.31.16.23.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 16:23:40 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <CAHbuEH4XVMaqUn7uLsGvw=54L8PkSZLfx3qUA3Gzw3TX8rr8pw@mail.gmail.com>
Date: Wed, 31 Jan 2018 19:23:39 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <270438B9-496C-4067-9D43-2DB6CB7F08BF@sn3rd.com>
References: <CAHbuEH4XVMaqUn7uLsGvw=54L8PkSZLfx3qUA3Gzw3TX8rr8pw@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SrPn3E0FfzU00BwJN4zOe_pJhOU>
Subject: Re: [TLS] AD Review, WAS: Re: WGLC for draft-ietf-tls-iana-registry-updates-03.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 01 Feb 2018 00:23:46 -0000

If anybody has any other views please let us know.

> On Jan 31, 2018, at 12:43, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
> 
> Thanks to the WG, chairs, and Stephen for your work on this draft and
> Ben  for the additional review comments.  The following nit and
> clarification points are in addition to Ben's suggested edits.  It
> looks long, but should result in no or very minor easy changes with
> text provided.
> 
> Section 9 -
> 
> Text nit:
>   Despite the following behavior being crazy, experience has shown that
>   some customers use the IANA registry as checklist against which to
>   measure an implementation's completeness and some implementers
>   blindly implement cipher suites.  Therefore, IANA [SHALL add/has
>   added] the following warning to the registry:
> Perhaps: s/crazy/unexpected and not advised/
> Or s/crazy/unexpected and NOT RECOMMENDED/

mt had the same reaction so put the following in the PR that addresses WGLC comments:

r/crazy/misguided

I wanted to avoid the 2119-language.

> Sections 8,10, 11, 13, and 15 all update the registration policy on an
> existing registry.  The rules for registration vary slightly and I'd
> like to confirm that this is what was intended:
> 
> Sections 8, 10, 11, 13
> Designated expert ensures the specification is publicly available.
> 
> Section 10, 13, 15
> Explicitly requires a standards track document.

s8 (TLS ExtensionType Values) we changed to spec required.

s10 (TLS Supported Groups) was changed to spec required by draft-ietf-tls-rfc4492bis.   draft-ietf-tls-rfc4492bis was really about moving EC cipher suites from informational track to stds track; that draft is sitting the RFC editor’s queue.  The blurb in this draft about stds track is just about how the initial values for the Recommended column got populated.

s11 (TLS ClientCertificateType Identifiers) we changed to spec required.

s13 (TLS Exporter Label Registry) we didn’t change the rules we just added a Recommended column.  The blurb in this draft about stds track is just about how the initial values for the Recommended column got populated.

s15 (TLS Certificate Types) we changed to spec required.

> Section 9 doesn't state either that the specification is publicly
> available or a standards track document is required.

s9 (TLS Cipher Suite Registry) was changed to spec required (and some for private use) and there’s a note at the end that section that adds:

   The designated expert [RFC8126] only ensures that
   the specification is publicly available.

> Next, I'd like to understand the WG's view on what "specification"
> suffices for registries that do not require a standards track
> document.  When you dig through 8126, we've had people on the IESG
> debate what is meant and people on the IESG change over time as do
> interpretations. Does this mean something as simple as an email to an
> IETF list that can be referenced and won't be deleted, a draft that is
> posted and never published, a standard in another standards body,
> etc.?  If you only intend it to mean the last 2, I think you're okay
> not elaborating further in the draft, but if an email is enough, I
> think you may need some text.  I'd use the phrase from 8126, section
> 4.6, "informal documentation, e.g. public IETF mailing list".
> 
> Relevant text from 8126:
> 
>   "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, including informal
>   documentation.”

The discussions I remember were about the latter two/three: a draft that is posted and never published or a standard in another standards body/industry consortium/university site/etc.

spt

> Best regards,
> Kathleen
> 
> On Wed, Jan 31, 2018 at 11:34 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
>> On the "better late than never" front, I've got some nits:
>> 
>> OLD:
>> 
>>       [...] A Standards Track document
>>      [RFC8126] is REQUIRED to register an extension with the value
>>      "Yes".
>> 
>> NEW:
>> 
>>      In order to register an extension with the value "Yes", a Standards
>> Track
>>      document [RFC8126] is REQUIRED.
>> 
>> Since not all standards-track documents must register such extensions/cipher
>> suites/etc.  (There are multiple occurrences of this text.)
>> 
>> 
>> Is the "Exporter Value" table in the document supposed to have a
>> "Recommended" column?
>> 
>> Let's also double-check that the "WARNING: Cryptographic algorithms[...]"
>> text does not always say "cipher suites listed here", even when talking
>> about (e.g.) HashAlgorithm and SignatureAlgorithm.
>> 
>> (Also, we can spell "SignatureAlgorithm" as not-"SignarureAlgorithm".)
>> 
>> Maybe capitalize "TBD" in "tbd but maybe tls-reg-review@ietf.org"?
>> 
>> 
>> OLD:
>> 
>>   Recommended algorithms regarded as secure for general use at the time
>>   of registration, however, cryptographic algorithms and parameters
>>   will be broken or weakened over time.
>> 
>> NEW:
>> 
>>   Recommended algorithms are regarded as secure for general use at the time
>>   of registration, however, cryptographic algorithms and parameters
>>   will be broken or weakened over time.
>> 
>> NOTES:
>> 
>> Add "are" to improve grammar.
>> 
>> 
>> -Ben
>> 
>> 
>> On 01/31/2018 08:35 AM, Sean Turner wrote:
>> 
>> I have one PR that address both the WGLC comments (from mt and ekr):
>> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/57
>> 
>> If you’ve got other suggested changes let me know and I can submit another
>> PR and do the final merges before you initiate the IETFLC.
>> 
>> Cheers,
>> 
>> spt
>> 
>> On Jan 30, 2018, at 16:54, Kathleen Moriarty
>> <kathleen.moriarty.ietf@gmail.com> wrote:
>> 
>> Great, thank you very much, Stephen!  I'll get it rolling towards
>> publication with last call starting soon.  I'll do my review in the
>> next couple of days.
>> 
>> Best regards,
>> Kathleen
>> 
>> On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> wrote:
>> 
>> Hi Kathleen,
>> 
>> The WGLC for this has expired.
>> 
>> There was only one explicit comment [1] saying to ship it.
>> The WG have chatted about this a bunch of times though so
>> FWIW I think it'd be fair to conclude there's pretty good
>> consensus for this.
>> 
>> Cheers,
>> S.
>> 
>> [1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html
>> 
>> On 15/01/18 21:34, Stephen Farrell wrote:
>> 
>> Hiya,
>> 
>> Kathleen's a bit busy at the moment so asked that, as shepherd,
>> I kick off the WGLC for this one (as the two chairs are authors).
>> The idea is that I'll summarise the WGLC thread to her and she
>> can then decide if this is ready to move forward.
>> 
>> So this starts a 2-week WGLC, ending on January 29th.
>> 
>> Cheers,
>> Shepherdy Stephen.
>> 
>> On 03/01/18 13:57, internet-drafts@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Transport Layer Security WG of the IETF.
>> 
>>       Title           : IANA Registry Updates for TLS and DTLS
>>       Authors         : Joe Salowey
>>                         Sean Turner
>>    Filename        : draft-ietf-tls-iana-registry-updates-03.txt
>>    Pages           : 16
>>    Date            : 2018-01-03
>> 
>> Abstract:
>>  This document describes a number of changes to (D)TLS IANA registries
>>  that range from adding notes to the registry all the way to changing
>>  the registration policy.  These changes were mostly motivated by WG
>>  review of the (D)TLS-related registries undertaken as part of the
>>  TLS1.3 development process.  This document updates many (D)TLS RFCs
>>  (see updates header).
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03
>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-03
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-03
>> 
>> 
>> 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.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> 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
>> 
>> --
>> PGP key change time for me.
>> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
>> NewWithOld sigs in keyservers.
>> Sorry if that mucks something up;-)
>> 
>> 
>> --
>> 
>> Best regards,
>> Kathleen
>> 
>> _______________________________________________
>> 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
>> 
>> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen