Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 21 November 2017 23:54 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 F3BB6129B79 for <tls@ietfa.amsl.com>; Tue, 21 Nov 2017 15:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 Lo6-QXn4HUUP for <tls@ietfa.amsl.com>; Tue, 21 Nov 2017 15:54:49 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087A7129451 for <tls@ietf.org>; Tue, 21 Nov 2017 15:54:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 02D67BE56; Tue, 21 Nov 2017 23:54:46 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyVqvaizNvlj; Tue, 21 Nov 2017 23:54:43 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 97F7EBE53; Tue, 21 Nov 2017 23:54:43 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1511308483; bh=0n5hAWDm1J37ijkMO1qNB0DT+FtfYc1ej/yRSL5MCCY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=SuFYE8F+5xJ9+54ei7lUI+aRTtfT8w08xWBxePfzOkG917sdDXk8F+xWFRoeRAR9t H5oCicalKcGJEiTuuszvn/IDv54+KN/VcSYN0ku+IiaAsoVaZ+T/soVSz08/VDkU5p zEGFoPHZe5k9yY3tOO5RscByizZS6fQ/IU2qtlCI=
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie> <CABkgnnVGVJN4PDQnDC5LbOnvsnv+DPecE4RQrvTvyVoK8aQDhw@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <16bf6215-f8dd-5d9c-22c3-a8814da13693@cs.tcd.ie>
Date: Tue, 21 Nov 2017 23:54:42 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CABkgnnVGVJN4PDQnDC5LbOnvsnv+DPecE4RQrvTvyVoK8aQDhw@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="TnJh9QWo8eX7de6jLEnSVM3L8iOFeaXkt"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/94aykmRajQ3UgCIr5DvWehTxe4A>
Subject: Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates
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: Tue, 21 Nov 2017 23:54:51 -0000


On 21/11/17 23:39, Martin Thomson wrote:
> IESG action seems appropriate for both.  

I'm fairly sure the WG discussed the No->Yes (or new Yes)
before and wanted standards action for that. I'd guess
that changing that might take some discussion. (FWIW, I'd
not support that change myself but maybe others would.)

If the No->Yes stuff doesn't change I'll take you as
arguing for a (4) below but correct me if that's wrong.

Cheers,
S.

> If we could include guidance
> around this (values with Yes should only include those for which the
> community currently has consensus are worth having available at the
> current time), tat would be awesom>
> On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
>>
>> Hiya,
>>
>> I just posted a draft shepherd write-up for this [1]. (The
>> write-up text was mostly written by Sean as it happens - for
>> which he has my thanks as it's boring as hell to do that:-)
>>
>> There are nits but only one substantive question that I don't
>> recall the WG discussing before (but maybe I'm forgetting).
>>
>> What is needed to change from Recommended == Yes down to
>> Recommended == No? Does that need a standards action (e.g.
>> with an RFC) or just IETF review or even maybe just IESG
>> action?
>>
>> In the current draft write-up I've put in the first as a
>> placeholder, as that's symmetric with the No->Yes change but
>> I think IESG action is probably ok if the WG wanted that as
>> the IESG probably won't go crazy and will likely do as the
>> WG want in such cases. If the WG do want to write a specific
>> foo-no-longer-recommended RFC it can do that in all cases,
>> and of course Yes->No transitions could be documented in an
>> RFC that documents a "replacement" Yes entry.
>>
>> So, unless this was already discussed....answers on a postcard
>> please - which'd we like:
>>
>> (1) say nothing (as in -02 draft)
>> (2) say standards action is required for a Yes->No transition
>> (3) say IETF review (i.e. an IETF last call) is required for a
>>     Yes->No transition
>> (4) say IESG action is required for a Yes->No transition
>> (5) something else
>>
>> And as a reminder the Recommended column is not about crypto
>> quality but is about things for which we have consensus that
>> they ought be widely implemented and available at the current
>> point in time. Those are related things but Recommended == No
>> does not imply crap-crypto even if crap-crypto will hopefully
>> imply Recommended == No.
>>
>> If nobody says anything I'll chat with Kathleen, Sean and Joe
>> and we'll pick a thing and that'll doubtless be quibbled about
>> during directorate reviews and IESG processing as these things
>> always are;-)
>>
>> But since I'd hope implementers will care about keeping up to
>> date with the set of Recommended == Yes things, I do hope that
>> folks are willing to express a preference here.
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shepherdwriteup/
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>